wikimedia / composer-merge-plugin

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

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

Open pikanji opened 1 year ago

pikanji commented 1 year 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