# Deploy fails - composer/installers & Composer V2 mismatch

**URL:** https://discourse.roots.io/t/deploy-fails-composer-installers-composer-v2-mismatch/20667
**Category:** bedrock
**Tags:** deploys
**Created:** 2021-04-23T12:32:52Z
**Posts:** 4

## Post 1 by @bjfresh — 2021-04-23T12:32:52Z

I’ve spent good portions of a couple of days trying to update a site, and have worked my way through a few snags only to bump up against an issue that has me stumped.

Up to now:

- PHP upgrade & “vlucas/phpdotenv”: “^5.3”,
- A bunch of plugin updates in composer
- Upgrade Composer to v2 (Which required a terminal-based IPv6 workaround on staging)
- Updated Bedrock manually
- Remove hirak/prestissimo since it’s v1-specific (thx Twansparent)
- Everything works locally
- I can now re-provision staging using Ansible
- Running “composer --version” on the local vagrant box or on staging shows v2 is running

…but deploys to staging don’t work, with a failure at

```
TASK [deploy : Install Composer dependencies]

The "composer/installers" plugin was skipped because it requires a Plugin API

version ("^1.0") that does not match your Composer installation ("2.0.0").

You may need to run composer update with the "--no-plugins" option. The

"philippbaschke/acf-pro-installer" plugin was skipped because it requires a

Plugin API version ("^1.0") that does not match your Composer installation

("2.0.0"). You may need to run composer update with the "--no-plugins"

option.
```

But in both site/composer.json and site/web/app/themes/mytheme/composer.json, I’m specifying

`"composer/installers": "^1.10.0"`

which is a version of the package that is supposed to be compatible with Composer 2

And in my composer.json, I’ve also replaced “philippbaschke/acf-pro-installer” with “pivvenit/acf-pro-installer”, so it’s intriguing that the philippbaschke package is referenced.

This suggested to me that there might be a caching issue, and I’ve run “composer clear-cache” in /srv/www/[mysite.com/current](http://mysite.com/current) to no effect.

I’m at a bit of a loss here.

Thanks in advance.

---

## Post 2 by @bjfresh — 2021-04-23T13:35:50Z

Hold up… removing composer.lock from the remote site appears to have fixed the issue. Now to make an attempt on production.

---

## Post 3 by @bjfresh — 2021-04-23T19:26:50Z

Now:

```
Problem 1
    - The requested package composer-plugin-api ^2.0 exists as composer-
plugin-api[1.1.0] but these are rejected by your constraint.
fatal: [www.mysite.com]: FAILED! => {"changed": true, "cmd": ["composer", "install", "--no-ansi", "--no-dev", "--no-interaction", "--no-progress", "--optimize-autoloader", "--no-scripts"], "delta": "0:00:00.156822", "end": "2021-04-23 18:57:39.018371", "rc": 2, "start": "2021-04-23 18:57:38.861549", "stderr_lines": ["Loading composer repositories with package information", "Installing dependencies from lock file", "Your requirements could not be resolved to an installable set of packages.", "", " Problem 1", " - The requested package composer-plugin-api ^2.0 exists as composer-plugin-api[1.1.0] but these are rejected by your constraint."], "stdout": "", "stdout_lines": []}
```

Strange, as both **site/composer.json** and **/site/web/app/themes/mytheme/composer.json** specify:

```
"composer/installers": "^1.10.0",
"composer-plugin-api": "^2.0"
```

and the deploy worked on staging

Again, I’ve run `composer clear-cache` and removed **composer.lock** in both locations.

Bewildered :slight_smile:

---

## Post 4 by @bjfresh — 2021-04-26T09:17:43Z

So on **production** , I also needed to remove **/vendor/**