Recently, as I upgraded composer to the newest version (2.1.3) , I've started having issues pulling down our satis repositories when running composer update.
The actual error I'm getting is:
usr@srv ~/test $ composer update
Loading composer repositories with package information
Updating dependencies
Nothing to modify in lock file
Installing dependencies from lock file (including require-dev)
Package operations: 87 installs, 0 updates, 0 removals
As there is no 'unzip' nor '7z' command installed zip files are being unpacked using the PHP zip extension.
This may cause invalid reports of corrupted archives. Besides, any UNIX permissions (e.g. executable) defined in the archives will be lost.
Installing 'unzip' or '7z' may remediate them.
- Syncing company/satis-company-lib (dev-master 349679e) into cache
[InvalidArgumentException]
Unknown downloader type: vcs. Available types: git, svn, fossil, hg, perforce, zip, rar, tar, gzip, xz, phar, file, path.
What's the reason for this error? I realize that it's complaining about the unzipping, but why would that suddenly have started to happen?
My satis config seems to generate vcs repos, but I can't find the config entry to change this (I'm only using git repos when building my satis packages). I also can't figure out how to add the vcs feature to my composer installation.
My satis configuration looks as follows:
{
"name": "Company PHP Repository",
"homepage": "https://satis:[email protected]",
"repositories": [
{
"type": "git",
"url": "https://satis:[email protected]/company/company-lib-php.git"
},
{
"type": "git",
"url": "https://satis:[email protected]/company/company-lib-yii-php.git"
}
],
"require-all": true,
"archive": {
"directory": "dist",
"format": "zip",
"prefix-url": "https://satis:[email protected]"
},
"require-dependencies": true,
"require-dev-dependencies": true
}
I'm guessing it's to do with the "archive" section not generating the correct dist packages, but I'm unsure.
Let's start out by saying that even after installing
unzipnothing is fixed.After a bunch of debugging, I found out that this logic was slightly changed in 2.1.0:
There's a few "fixes" to this that I've found so far, but they're really more hacks than actual fixes.
Adding
preferred-installto yourcomposer.jsonfileIf you add a composer.json entry of
config.preferred-installyou can also avoid this new behavior:You can either use the full package name (
"foocompany/lib": "auto"), a prefix ("foocompany/*": "auto") or all packages by using a start ("*": "auto").Running command with flag
You can simply call
composer update --prefer-install=autoinstead ofcomposer update, but this obviously doesn't fix the issue that arises when callingcomposer update.Reverting to an older version of composer
You can always revert to other versions of composer by using
composer self-update <version>. In the case of downgrading to something before 2.1.0, you can install2.0.14:After this you can run
composer updatelike you could before without any issues.Note: Please don't run old versions of software unless you absolutely have to.
The last resort
If nothing else works, you can usually make it work by forcing composer to fetch from the source instead. Simply use
composer update --prefer-source.