Open pikanji opened 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().
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.
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.
my workaround: composer install --no-plugins --no-scripts ; composer install
Is it possible to add option to avoid
composer update
is executed aftercomposer install
is executed? Although I expected to deploy packages with exact version combinations recorded in composer.lock which was tested, it was unexpectedly overwritten bycomposer 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 runscomposer install
to install packages recorded in composer.lock including those merged by composer-merge-pluign. However, after this, composer-merge-plugin runscomposer 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
aftercomposer install
.Like this: https://github.com/wikimedia/composer-merge-plugin/compare/master...pikanji:composer-merge-plugin:option-to-prevent-automatic-update?expand=1
Thanks.