wikimedia / composer-merge-plugin

Merge one or more additional composer.json files at Composer runtime
MIT License
938 stars 160 forks source link

Option to avoid composer update being executed after composer install #252

Open pikanji opened 2 years ago

pikanji commented 2 years ago

Is it possible to add option to avoid composer update is executed after composer install is executed? Although I expected to deploy packages with exact version combinations recorded in composer.lock which was tested, it was unexpectedly overwritten by composer update executed by composer-merge-plugin, resulting deploying something not tested. My deployment places my source code to the server without any composer dependency, then runs composer install to install packages recorded in composer.lock including those merged by composer-merge-pluign. However, after this, composer-merge-plugin runs composer update because it is the first time composer-merge-plugin is installed on the sever. For my system, this behavior is unnecessary since the dependency is already merged in composer.lock, and even problematic since it make installation with composer.lock meaningless.

This is similar issue to #235 , yet I'm hoping to have an option to suppress this behavior of force executing composer update after composer install.

Like this: https://github.com/wikimedia/composer-merge-plugin/compare/master...pikanji:composer-merge-plugin:option-to-prevent-automatic-update?expand=1

Thanks.

bd808 commented 1 year ago

@pikanji the diff of your fork looks reasonable. If you add some test coverage and documentation and then submit a pull-request it would be likely to be merged. I think this could be a reasonable fix for #235 as well. The behavior that @DiegoMow is reporting there is quite likely caused by the same $this->state->isFirstInstall() === true in onPostInstallOrUpdate().

bd808 commented 1 year ago

I think you are also going to need to check $this->state->isLocked() to determine if composer-merge-plugin itself is being installed from a composer.lock dependency or not. Otherwise you are still in the chicken and egg problem described at https://github.com/wikimedia/composer-merge-plugin/issues/170#issuecomment-751943604 where the plugin does not know if it has ever been run or not.

schmunk42 commented 1 year ago

From #170 linked above:

This is a classic "chicken and egg" problem. The second run is needed because composer-merge-plugin is not available to Composer until it has been installed. If the second installation run was not invoked by the plugin itself then no packages installed by composer-merge-plugin would be installed until a second manual run was made.

If you're running an install you need a .lock file otherwise it is (de-facto) an update.

With composer install you actually do not even need the plugin since everything is already resolved. Additionally: composer-merge-plugin does not check if the contents of a merged .json have been changed - that's a separate issue which might be addressed.

When you're running composer update on first install you always need to run update twice because of the chicken-egg problem, regardless of the proposed auto-update option.

Bottom line is: Do not touch .lock file when using install - it completely defeats it's purpose.

priyadi commented 1 year ago

my workaround: composer install --no-plugins --no-scripts ; composer install

Ambient-Impact commented 3 months ago

Ran in to this oddity as well where Composer was inexplicably updating when I was simply doing composer install in the branch where we started using this plug-in and was starting to wonder if Composer was gaslighting me until I vaguely remembered something about this plug-in doing this. 😂 I tried @priyadi's workaround but that had all sorts of unintended side effects since we use several other plug-ins, including composer/installers, meaning that things were installed into the vendor directory and not in the correct locations. A much better workaround:

composer config allow-plugins.wikimedia/composer-merge-plugin false
composer install
composer config allow-plugins.wikimedia/composer-merge-plugin true
composer install

This prevents just this plug-in from running during a fresh check out so that Composer installs the locked versions, and then re-enables the plug-in and runs the second composer install to satisfy the merge plug-in.

schmunk42 commented 3 months ago

Just FYI: We‘re running this branch https://github.com/wikimedia/composer-merge-plugin/pull/257/files without problems for over 1,5 years. Just the event hook is removed.