Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

composer install --no-scripts installs 0.13.4 instead of 0.15.0 #876

Open
someniatko opened this issue Dec 3, 2019 · 16 comments · Fixed by #1496
Open

composer install --no-scripts installs 0.13.4 instead of 0.15.0 #876

someniatko opened this issue Dec 3, 2019 · 16 comments · Fixed by #1496
Assignees
Labels
Milestone

Comments

@someniatko
Copy link

someniatko commented Dec 3, 2019

Question Answer
Infection version 0.13.4 (infection.phar --version) but intended is 0.15.0
Test Framework version PHPUnit 8.4.3
PHP version 7.4.0
Platform Alpine Linux, also Windows 10 - results are the same
Github Repo -
  1. add infection/infection ^0.15 to your composer.json file
  2. remove vendor folder and composer.lock file for the clean experiment
  3. run composer install --no-scripts (composer.lock file will be generated)
  4. observe that in composer.lock version is set to correct one (for now it's 0.15.0)
  5. run vendor/bin/infection --version.

Expected:
Infection - PHP Mutation Testing Framework 0.15.x@<hash>

Actual:
Infection - PHP Mutation Testing Framework 0.13.4@f0f8327f5e60d1a7d8ab4ea01074c6250ab96f57

@someniatko someniatko changed the title composer install --prefer-dist installs 0.13.4 instead of 0.15.0 composer install --no-scripts installs 0.13.4 instead of 0.15.0 Dec 3, 2019
@theofidry
Copy link
Member

maybe a composer why infection/infection would tell? Btw it's usually better to do (provided it's an app not a lib) composer update xx/yy eventually with the --with-dependencies flag than removing the composer.lock

@someniatko
Copy link
Author

@theofidry i don't have a composer.lock file because i am developing a library, therefore the .lock file is not committed to the git (it makes no sense anyway, because the project using the library will define the final list of dependencies). Then in CI i execute composer install and then launch tests. However, if i use --no-scripts flag, for some reason it installs "partially" or so. Maybe i have indeed the 0.15.0 version, however, for some reason it identifies itself as 0.13.4 if some scripts are not executed.

@someniatko
Copy link
Author

Yes, it looks like it's indeed so:

user> composer why infection/infection
<my lib name> dev-master  requires (for development)  infection/infection (^0.15)
user> php74 vendor/bin/infection --version
You are running Infection with Xdebug enabled.
Infection - PHP Mutation Testing Framework 0.13.4@f0f8327f5e60d1a7d8ab4ea01074c6250ab96f57

however, infection still identifies itself as 0.13.4

@maks-rafalko
Copy link
Member

maks-rafalko commented Dec 4, 2019

We are relying on ocramius/package-versions package:

parent::__construct(self::NAME, Versions::getVersion('infection/infection'));

composer install
Loading composer repositories with package information
Installing dependencies (including require-dev) from lock file
Nothing to install or update
Generating autoload files

# here is a key moment

ocramius/package-versions:  Generating version class...
ocramius/package-versions: ...done generating version class

When I use --no-scripts, no versions are generated for this package:

composer install --no-scripts
Loading composer repositories with package information
Installing dependencies (including require-dev) from lock file
Nothing to install or update
Generating autoload files

I just tried to install infection/infection to the new dir and ran composer install --no-scripts, followed by bin/infection -V, which produces Fatal Error:

bin/infection -V
PHP Fatal error:  Uncaught OutOfBoundsException: Required package "infection/infection" is not installed: cannot detect its version in /private/tmp/infection/vendor/ocramius/package-versions/src/PackageVersions/FallbackVersions.php:44
Stack trace:
[...]

@someniatko I guess you have 0.13.4 somehow cached by ocramius/package-versions on your CI. Is it possible?


So, this seems like a bug? @infection/core?
Should we use a fallback for cases when Versions::getVersion() is used and --no-scripts is aded to composer install?

@sanmai
Copy link
Member

sanmai commented Dec 4, 2019

Catching that OutOfBoundsException is not a problem, we can do that. Testing it is another question. Testing it while collecting coverage is yet another problem.

I tend to think we can catch that exception, and be done, for now.

@sanmai
Copy link
Member

sanmai commented Dec 4, 2019

It is, and there's where it throws that OutOfBoundsException, or UnexpectedValueException for that matter.

@maks-rafalko
Copy link
Member

I think we just need to update to the latest version and everything should work out of the box. Currently, we are on 1.4.0, latest is 1.5.1

@someniatko
Copy link
Author

@maks-rafalko you cannot, package-versions 1.5.x require PHP 7.3

@someniatko
Copy link
Author

someniatko commented Dec 4, 2019

@maks-rafalko btw, i tested on two test projects (just created new folders with composer.json only):

  • one uses PHP 7.4 and package-versions 1.5.1,
  • the second uses PHP 7.2 and package-versions 1.4.2

both have the same problem, after composer install --no-scripts vendor/bin/infection --version shows some irrelevant version (for me in PHP 7.2 project it shows "0.7.1")

@scaytrase
Copy link
Contributor

This is related to #1007 and Ocramius/PackageVersions#116 Shortly: when using --no-scripts PackageVersions are not generated and they utilize ocramius/package-versions/composer.lock content, which locked to 0.13.4

There is nothing to do with it in this package, the only workaround is not to rely on PackageVersions to detect this package version.

@maks-rafalko
Copy link
Member

@maks-rafalko you cannot, package-versions 1.5.x require PHP 7.3

Infection is using PHP 7.3 on master, can we fix this issue with upgrading ocramius/package-versions?

@scaytrase
Copy link
Contributor

scaytrase commented Mar 10, 2020 via email

@maks-rafalko
Copy link
Member

Is it still an issur @scaytrase ? We are using ocramius/package-versions 1.9.0 at the moment

@scaytrase
Copy link
Contributor

Sorry, no idea I'm not part of that project anymore to check. This should be fixed since 1.10 using composer 2 api

maks-rafalko added a commit that referenced this issue Mar 14, 2021
… 7.4.0 to 7.4.7 as `package-versions` requires

Fixes #876
@maks-rafalko maks-rafalko self-assigned this Mar 14, 2021
@maks-rafalko maks-rafalko added this to the 0.22.0 milestone Mar 14, 2021
maks-rafalko added a commit that referenced this issue Mar 14, 2021
… 7.4.0 to 7.4.7 as `package-versions` requires (#1496)

Fixes #876
@maks-rafalko
Copy link
Member

Had to revert this change since it breaks Phar creation, see #1520

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging a pull request may close this issue.

5 participants