Removing this package on install results in file access error

[Xerkus]

Steps to reproduce:

• add as a dev dependency
• run composer install
• run composer install --no-dev

[ErrorException]
file_put_contents(vendor/ocramius/package-versions/src/PackageVersions/Versions.php): failed to open stream: No such file or directory

[Ocramius]

Seen this before, but I don't have a resolution path.

We could probably check for packages scheduled for removal, then skip generation if this package is in the list.

[rask]

Happening here too. Will resort to just keeping to dev-packages as is for the time being.

[Ocramius]

Will resort to just keeping to dev-packages as is for the time being.

Unsure what you mean with that?

Also, I think that the best solution would be for me to move where the Versions class is dumped (maybe vendor/.package-versions/Version.php, then replace the autoload definitions?)

[peterjaap]

Only way to skip this error for me is to install it with --no-scripts. :(

[kubawerlos]

Looks like a composer thing. Consider following sequence of commands (in an empty directory):

composer init --no-interaction
composer require --dev ocramius/package-versions
composer install --no-dev # This one raises ErrorException
composer install --no-dev # No error

First run of composer install --no-dev registers plugin before the package is removed, but activates it after removing. Also the package checks if is installed relating on composer.lock which is updated later (BTW is the comment in line 87 correct?).

Replacing mentioned check with testing if directory from Installer::locateRootPackageInstallPath exists would solve the problem, wouldn't it?

[Majkl578]

Just ran into this today because PHPStan now depends on PackageVersions indirectly since 0.8.1.
Workaround is to run install with --no-scripts and then run scripts separately with composer run-script.

[JeroenDeDauw]

Also running into this https://travis-ci.com/wmde/fundraising-backend/jobs/88894597

[Majkl578]

How about using Composer\Installer\PackageEvents::POST_PACKAGE_UNINSTALL to detect uninstallation of this package and disable installation in such case?

[Ocramius]

@Majkl578 how would that work? Just listen to the event, collect the package names, stop execution?

[Majkl578]

@Ocramius Listen to the event and look for UninstallOperation where $op->getPackage()->getName() === 'ocramius/package-versions'.
If received, either unregister itself from the post-install event subscription (if possible) or store information about being uninstalled (private property -> state -> meh?) and simply abort execution in the dumpVersionsClass().
Is that even possible? :P

[Ocramius]

(private property -> state -> meh?)

SHINY!

Is that even possible? :P

It all depends on the amount of sleepless nights that I can bring to @Seldaek

[Jean85]

I would like to propose an other solution: intervening directly on the error cause.

That should be done here, checking if the package folder exists; if it does not, we could skip it, maybe outputting a nice explanation message.

Do you like it? I will probably write a brief PR with this approach...

[Ocramius]

Handled in #46