search

PHPCSStandards / composer-installer

Composer installer for PHP_CodeSniffer coding standards
https://packagist.org/packages/dealerdirect/phpcodesniffer-composer-installer
MIT License
549 stars 36 forks source link

Installation failure on Ubuntu 20 #134

Closed tomjn closed 3 years ago

tomjn commented 3 years ago

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:

COMPOSER_BIN_DIR="bin" noroot composer require --update-with-all-dependencies "dealerdirect/phpcodesniffer-composer-installer" "wp-coding-standards/wpcs" "automattic/vipwpcs" "phpcompatibility/php-compatibility" "phpcompatibility/phpcompatibility-paragonie" "phpcompatibility/phpcompatibility-wp" --no-ansi --no-progress

I managed to simplify the command that fails down to this command:

composer require "dealerdirect/phpcodesniffer-composer-installer"

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:

vagrant@vvv:/srv/www/phpcs$ COMPOSER_BIN_DIR="bin" composer require "dealerdirect/phpcodesniffer-composer-installer"
Using version ^0.7.1 for dealerdirect/phpcodesniffer-composer-installer
./composer.json has been created
Running composer update dealerdirect/phpcodesniffer-composer-installer
Loading composer repositories with package information
Updating dependencies
Lock file operations: 2 installs, 0 updates, 0 removals
  - Locking dealerdirect/phpcodesniffer-composer-installer (v0.7.1)
  - Locking squizlabs/php_codesniffer (3.5.8)
Writing lock file
Installing dependencies from lock file (including require-dev)
Package operations: 2 installs, 0 updates, 0 removals
  - Installing squizlabs/php_codesniffer (3.5.8): Extracting archive
    Skipped installation of bin bin/phpcs for package squizlabs/php_codesniffer: file not found in package
    Skipped installation of bin bin/phpcbf for package squizlabs/php_codesniffer: file not found in package
  - Installing dealerdirect/phpcodesniffer-composer-installer (v0.7.1): Extracting archive
Plugin initialization failed (include(/srv/www/phpcs/vendor/dealerdirect/phpcodesniffer-composer-installer/src/Plugin.php): failed to open stream: No such file or directory), uninstalling plugin
  - Removing dealerdirect/phpcodesniffer-composer-installer (v0.7.1)
    Install of dealerdirect/phpcodesniffer-composer-installer failed

Installation failed, deleting ./composer.json.

  [RuntimeException]                                                                          
  Could not delete /srv/www/phpcs/vendor/dealerdirect/phpcodesniffer-composer-installer/src:  

require [--dev] [--dry-run] [--prefer-source] [--prefer-dist] [--fixed] [--no-suggest] [--no-progress] [--no-update] [--no-install] [--no-scripts] [--update-no-dev] [-w|--update-with-dependencies] [-W|--update-with-all-dependencies] [--with-dependencies] [--with-all-dependencies] [--ignore-platform-req IGNORE-PLATFORM-REQ] [--ignore-platform-reqs] [--prefer-stable] [--prefer-lowest] [--sort-packages] [-o|--optimize-autoloader] [-a|--classmap-authoritative] [--apcu-autoloader] [--apcu-autoloader-prefix APCU-AUTOLOADER-PREFIX] [--] [<packages>]...

Strangely, the file it can't open is present:

vagrant@vvv:/srv/www/phpcs$ ls vendor/dealerdirect/phpcodesniffer-composer-installer/src/
Plugin.php

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

Question Answer
OS Ubuntu 20 in a Virtualbox vagrant VM
PHP version 7.4.16
Composer version Composer version 2.0.11 2021-02-24 14:57:23
PHP_CodeSniffer version failed to install due to aforementioned problem
Dealerdirect PHPCS plugin version v0.7.1
Install type Composer project local

Output of vendor/bin/phpcs --config-show: _failed to install due to the problem

Tested against master branch?

tomjn commented 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$
tomjn commented 3 years ago

"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$
jrfnl commented 3 years ago

@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.

tomjn commented 3 years ago

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

jrfnl commented 3 years ago

@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.

jrfnl commented 3 years ago

@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.

Seldaek commented 3 years ago

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.

tomjn commented 3 years ago

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

jrfnl commented 3 years ago

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.