Ocramius/PackageVersions is not compatible with composer configuration "lock: false"

[windaishi]

Composer has introduced the option to disable the lock file. This is helpful for libraries (for example). See: https://getcomposer.org/doc/06-config.md#lock

When the lock file is disabled but composer installs ocramius/package-versions because it is somewhere in the dependency graph, composer will fail with the following error message:

[LogicException]
No lockfile found. Unable to read locked packages

Of course it fails, because the lock file is missing on purpose.

I assume that ocramius/package-versions is accessing the lock file to find out the installed package versions. Instead it should use the file installed.json. Maybe, for backwards-compatibility reasons, it should do that only if the lock file is disabled explicitly.

Stack trace:

Exception trace:
 () at phar:///usr/local/bin/composer/src/Composer/Package/Locker.php:267
 Composer\Package\Locker->getLockData() at /Users/manuelkress/Pickware/ShopwareNext/Plugins/shopware-plugins/bundles/shopware-plugins-money-bundle/vendor/ocramius/package-versions/src/PackageVersions/Installer.php:209
 PackageVersions\Installer::getVersions() at n/a:n/a
 iterator_to_array() at /Users/manuelkress/Pickware/ShopwareNext/Plugins/shopware-plugins/bundles/shopware-plugins-money-bundle/vendor/ocramius/package-versions/src/PackageVersions/Installer.php:115
 PackageVersions\Installer::dumpVersionsClass() at n/a:n/a
 call_user_func() at phar:///usr/local/bin/composer/src/Composer/EventDispatcher/EventDispatcher.php:164
 Composer\EventDispatcher\EventDispatcher->doDispatch() at phar:///usr/local/bin/composer/src/Composer/EventDispatcher/EventDispatcher.php:96
 Composer\EventDispatcher\EventDispatcher->dispatchScript() at phar:///usr/local/bin/composer/src/Composer/Autoload/AutoloadGenerator.php:322
 Composer\Autoload\AutoloadGenerator->dump() at phar:///usr/local/bin/composer/src/Composer/Installer.php:307
 Composer\Installer->run() at phar:///usr/local/bin/composer/src/Composer/Command/InstallCommand.php:122
 Composer\Command\InstallCommand->execute() at phar:///usr/local/bin/composer/vendor/symfony/console/Command/Command.php:245
 Symfony\Component\Console\Command\Command->run() at phar:///usr/local/bin/composer/vendor/symfony/console/Application.php:835
 Symfony\Component\Console\Application->doRunCommand() at phar:///usr/local/bin/composer/vendor/symfony/console/Application.php:185
 Symfony\Component\Console\Application->doRun() at phar:///usr/local/bin/composer/src/Composer/Console/Application.php:281
 Composer\Console\Application->doRun() at phar:///usr/local/bin/composer/vendor/symfony/console/Application.php:117
 Symfony\Component\Console\Application->run() at phar:///usr/local/bin/composer/src/Composer/Console/Application.php:113
 Composer\Console\Application->run() at phar:///usr/local/bin/composer/bin/composer:61
 require() at /usr/local/bin/composer:24

[Ocramius]

A possible solution (related: #101) is to install with --no-scripts, which defeats the purpose of this package, but solves your immediate woe.

When installing with --no-scripts, if composer.lock cannot be found, the package already falls back to trying to read installed.json (or the other way around: can't remember clearly).

Two considerations have to be added to the pile here:

1. The fact that Composer\Package\Locker now throws an exception seems to be an upstream BC break.
2. Shopware is a bit of a terrible monster: "a snake that eats its own tail", in German-ish slang, so I'm fairly sure it should be fixed there by using a standard installation approach, instead of hacking their way even further into a composer nightmare :-)

Considering the above, I'm inclined to not fix this problem in the 1.x series, and instead get it implicitly fixed with 2.0.0.

Specifically, the only reason why I still need the lock file in the 1.x series is to support the codegen for PackageVersions\Versions::ROOT_PACKAGE_NAME, which is to be deprecated and removed as per #139 (comment)

Therefore, adding 2.0.0 milestone here, and this will be fixed with #139.

[windaishi]

Hey, thanks for you fast reply!

When installing with --no-scripts, if composer.lock cannot be found, the package already falls back to trying to read installed.json (or the other way around: can't remember clearly).

Thanks for the hint! Currently we do not have to workaround the problem in this particular case, as it appeared only because of another problem. Anyway, I think this is a bug that should be fixed and therefore I reported it ;). This is also the reason why it is totally okay for us, that this is not fixed immediately.

In case someone has the same problem and stumbles across this thread: This is also a working work around:

• Remove the config lock: false from composer.json
• Add the following to scripts section:

       "post-install-cmd": [
           "@remove-lock-file"
       ],
       "post-update-cmd": [
           "@remove-lock-file"
       ],
       "remove-lock-file": [
           "# Workaround as long as composer does not support the corresponding config option to disable composer.lock",
           "rm composer.lock"
       ],
  

(We used this workaround while composer did not support to disable the lock file.)

Shopware is a bit of a terrible monster: "a snake that eats its own tail", in German-ish slang, so I'm fairly sure it should be fixed there by using a standard installation approach, instead of hacking their way even further into a composer nightmare :-)

Yeah, "Shopware" appears in the stack trace but actually I think the problem is almost not Shopware related. The package that requires ocramius/package-versions is ocramius/proxy-manager.

Therefore, adding 2.0.0 milestone here, and this will be fixed with #139.

Nice 👍 I'm looking forward to it.