Open pikanji opened 2 years 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
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.
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.
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.