Closed tomjn closed 3 years ago
So I can install this composer.json
:
{
"require": {
"squizlabs/php_codesniffer": "^3.5",
"wp-coding-standards/wpcs": "^2.3",
"automattic/vipwpcs": "^2.2",
"phpcompatibility/php-compatibility": "^9.3",
"phpcompatibility/phpcompatibility-paragonie": "^1.3",
"phpcompatibility/phpcompatibility-wp": "^2.1"
}
}
But not this:
{
"require": {
"squizlabs/php_codesniffer": "^3.5",
"wp-coding-standards/wpcs": "^2.3",
"automattic/vipwpcs": "^2.2",
"phpcompatibility/php-compatibility": "^9.3",
"phpcompatibility/phpcompatibility-paragonie": "^1.3",
"phpcompatibility/phpcompatibility-wp": "^2.1",
"dealerdirect/phpcodesniffer-composer-installer": "^0.7.1"
}
}
vendor/bin/phpcs --config-show
:
vagrant@vvv:/srv/www/phpcs$ vendor/bin/phpcs --config-show
Using config file:
vagrant@vvv:/srv/www/phpcs$
"dealerdirect/phpcodesniffer-composer-installer": "dev-master"
does succeed:
vagrant@vvv:/srv/www/phpcs$ composer update
Loading composer repositories with package information
Updating dependencies
Lock file operations: 0 installs, 1 update, 0 removals
- Upgrading dealerdirect/phpcodesniffer-composer-installer (v0.7.1 => dev-master 97aa24e)
Writing lock file
Installing dependencies from lock file (including require-dev)
Package operations: 1 install, 0 updates, 0 removals
- Syncing dealerdirect/phpcodesniffer-composer-installer (dev-master 97aa24e) into cache
- Installing dealerdirect/phpcodesniffer-composer-installer (dev-master 97aa24e): Cloning 97aa24eee4 from cache
Generating autoload files
PHP CodeSniffer Config installed_paths set to ../../automattic/vipwpcs,../../phpcompatibility/php-compatibility,../../phpcompatibility/phpcompatibility-paragonie,../../phpcompatibility/phpcompatibility-wp,../../sirbrillig/phpcs-variable-analysis,../../wp-coding-standards/wpcs
vagrant@vvv:/srv/www/phpcs$
@tomjn Pff.. interesting one. I'm not a position to test this, other than via CI as I don't have access locally to Ubuntu bionic 20.
I am wondering though whether this is really an issue with this plugin or rather an issue with Composer itself ? /cc @Seldaek
As a side-note, and most likely unrelated to the above related issue, I'm wondering why you have the below set of requirements:
{
"require": {
"squizlabs/php_codesniffer": "^3.5",
"wp-coding-standards/wpcs": "^2.3",
"automattic/vipwpcs": "^2.2",
"phpcompatibility/php-compatibility": "^9.3",
"phpcompatibility/phpcompatibility-paragonie": "^1.3",
"phpcompatibility/phpcompatibility-wp": "^2.1",
"dealerdirect/phpcodesniffer-composer-installer": "^0.7.1"
}
}
To me, this seems very prone to version constraint conflicts, as most of these requirements also require your other requirements.
Which of these are actually your dependencies ? And which of these requirement are in actual fact dependencies of your dependencies ? For the latter, you're better off letting the dependency manage the required versions.
Just looking at the above, it could be simplified down to the below and the same packages would still be installed:
{
"require": {
"automattic/vipwpcs": "^2.2",
"phpcompatibility/phpcompatibility-wp": "^2.1",
"dealerdirect/phpcodesniffer-composer-installer": "^0.7.1"
}
}
Heads-up: as of the next release of any of these packages, you won't need to require this plugin dealerdirect/phpcodesniffer-composer-installer
yourself anymore either, as all PHPCompatibility packages, VIPCS 2.3.0+ and WPCS 3.0.0+ will all start to require it as a non-dev dependency.
Oh the specifics of the composer.json
are just what composer require ...
created when I ran the command without this plugin:
COMPOSER_BIN_DIR="bin" composer require --update-with-all-dependencies "wp-coding-standards/wpcs" "automattic/vipwpcs" "phpcompatibility/php-compatibility" "phpcompatibility/phpcompatibility-paragonie" "phpcompatibility/phpcompatibility-wp"
We don't currently have a composer.json
in the provisioner, but it was useful to know the exact version of dependencies it chose as well as to test the master
branch vs 0.7.1. Both composer.json
's mentioned above ran via composer v2
@tomjn Whether set via the composer.json
or via the command, doesn't really matter. The command does the same: it requires underlying dependencies of your dependencies.
@tomjn Okay, so I've done some testing via CI without using Vagrant and I cannot reproduce the issue.
I've tried a number of variations of the command, including one with the COMPOSER_BIN_DIR
environment variable and all install fine and the standards installed are correctly registered as can be seen in the "Verify" step.
For details of the tests I ran, see:
The only thing I'm left to wonder about is the noroot
in the command in the original issue description.
Other than that, this does not seem to be an issue with this plugin, and probably not even with Composer.
At a guess, I'd say it feels more like an issue with Vagrant on Ubuntu 20, possibly in combination with the noroot
argument.
Sorry that I can't be of more help, but hoping this gives you some clues to continue investigating.
Hey, this is a known issue with the vagrant filesystem.. i tried working around it in composer a few days ago but it appears the fix isn't working. You may try as well though maybe you are luckier https://github.com/composer/composer/issues/9627#issuecomment-795173868
There's also a working workaround in that thread.
VirtualBox* not just Vagrant, a reading of that ticket suggests the cause is micro-caches. This could be confirmed by disabling them and retesting, although FS performance would be compromised, I'm unsure how to configure a VirtualBox VM to test this, and technically this also impacts non-vagrant/virtualbox environments if this theory is correct
Thanks @Seldaek for confirming my hunch that this is not an issue with this plugin, or even really with Composer. With that in mind, I'm going to close this ticket.
@tomjn I suggest you follow the ticket Jordi pointed to.
Problem/Motivation
On VVV ( Ubuntu 18.04 )we run a command under PHP 7.4 to install PHPCS with this package.
Recently a contributor tried to upgrade us to an Ubuntu 20 box, but provisioning fails during PHPCS package installation.
This is the command we run, which works on Ubuntu 18 Bionic:
I managed to simplify the command that fails down to this command:
This happens under both v1 and v2 of composer, when ran in an empty folder that has the same ownership as the current user (
vagrant
)Expected behaviour
I expected the package to be installed
Actual behaviour
The package fails with this error:
Strangely, the file it can't open is present:
Steps to reproduce
This PR switches the VVV box to Ubuntu 20, and running the command while SSH'd in as the
vagrant
user also generates the same error:https://github.com/Varying-Vagrant-Vagrants/VVV/pull/2389
Proposed changes
I don't understand the cause of the problem since it's complaining that a file that's present is not present
Environment
Output of
vendor/bin/phpcs --config-show
: _failed to install due to the problemTested against
master
branch?master
branch.