Closed mcaskill closed 3 years ago
@tobias-kuendig could you test this with October & Composer 1.0 & 2.0?
Note: I last tested these changes with Composer v1.10.15 / v2.0.2. I do am unaware if it works in latest versions.
When will it release for composer 2.0 ?
are looking forward to
Thanks for the huge work, any ideas when it will merge.
Tested with Composer 2.0.3. Works for me. Thanks!
@sebschaefer how you solved that? which version do u use?
You can check this PR in your projects by requiring wikimedia/composer-merge-plugin:dev-feature/composer-v2
and adding the https://github.com/mcaskill/composer-merge-plugin.git
vcs repository to your composer.json file.
I just checked this with concrete5 and this PR fixes the issue.
Hello,
Thanks to everyone involved in this PR.
This PR worked for me too, thanks!
This PR seems to work mostly correctly. However, I am getting this error when installing with Composer 1.10.1:
PHP Fatal error: Uncaught Error: Call to undefined method Composer\Factory::getLockFile() in /mnt/data/workspace/drupal_d9/vendor/wikimedia/composer-merge-plugin/src/MergePlugin.php:323
Stack trace:
#0 [internal function]: Wikimedia\Composer\MergePlugin->onPostInstallOrUpdate()
#1 /usr/share/php/Composer/EventDispatcher/EventDispatcher.php(164): call_user_func()
#2 /usr/share/php/Composer/EventDispatcher/EventDispatcher.php(96): Composer\EventDispatcher\EventDispatcher->doDispatch()
#3 /usr/share/php/Composer/Installer.php(338): Composer\EventDispatcher\EventDispatcher->dispatchScript()
#4 /usr/share/php/Composer/Command/InstallCommand.php(122): Composer\Installer->run()
#5 /usr/share/php/Symfony/Component/Console/Command/Command.php(255): Composer\Command\InstallCommand->execute()
#6 /usr/share/php/Symfony/Component/Console/Application.php(934): Symfony\Component\Console\Command\Command->run()
#7 /usr/share/php/Symfony/Component/Console/Application.php(273): Symfony\Component\Console\Application->doRunCommand()
#8 /usr/share in /mnt/data/workspace/drupal_d9/vendor/wikimedia/composer-merge-plugin/src/MergePlugin.php on line 323
Fatal error: Uncaught Error: Call to undefined method Composer\Factory::getLockFile() in /mnt/data/workspace/drupal_d9/vendor/wikimedia/composer-merge-plugin/src/MergePlugin.php:323
Stack trace:
#0 [internal function]: Wikimedia\Composer\MergePlugin->onPostInstallOrUpdate()
#1 /usr/share/php/Composer/EventDispatcher/EventDispatcher.php(164): call_user_func()
#2 /usr/share/php/Composer/EventDispatcher/EventDispatcher.php(96): Composer\EventDispatcher\EventDispatcher->doDispatch()
#3 /usr/share/php/Composer/Installer.php(338): Composer\EventDispatcher\EventDispatcher->dispatchScript()
#4 /usr/share/php/Composer/Command/InstallCommand.php(122): Composer\Installer->run()
#5 /usr/share/php/Symfony/Component/Console/Command/Command.php(255): Composer\Command\InstallCommand->execute()
#6 /usr/share/php/Symfony/Component/Console/Application.php(934): Symfony\Component\Console\Command\Command->run()
#7 /usr/share/php/Symfony/Component/Console/Application.php(273): Symfony\Component\Console\Application->doRunCommand()
#8 /usr/share in /mnt/data/workspace/drupal_d9/vendor/wikimedia/composer-merge-plugin/src/MergePlugin.php on line 323
(Only the first time, the next composer install
don't trigger the error.)
[…] I am getting this error when installing with Composer 1.10.1:
@prudloff-insite Thanks, I'll check this out.
Also it looks like the plugin now runs composer update
after the first install?
This is a problem when running composer install
on a CI.
We expect the locked dependencies to be installed as is and not everything to be updated.
Also it looks like the plugin now runs
composer update
after the first install? This is a problem when runningcomposer install
on a CI. We expect the locked dependencies to be installed as is and not everything to be updated.
@prudloff-insite Good point! I had a feeling there was some flaw.
When the plugin is first installed, it triggers a second install / update.
In Composer 2, I'm forcing an update to add the inherited dependencies to the lock file but this is clearly an issue with existing root dependencies that might not want to be updated.
I'll try to look into it soon. If you have any suggestions, I'm all ears.
Would it be possible to run composer update
only on dependencies from the merged file?
Or at least add a flag that we can use on the CI to tell it not to update the lock file.
Would it be possible to run
composer update
only on dependencies from the merged file?Or at least add a flag that we can use on the CI to tell it not to update the lock file.
@prudloff-insite There must be a way to handle this. I need to look into this. There's been quite a few changes in Composer since late September (when I initially put together this proposal).
I'm reading through my code and I'm seeing a potential flaw in my logic related to merging extra requirements.
If someone were to add/remove/change the requirements of a nested composer file and triggered an install/update of an already installed root composer file, I think the root package will fail to alter its lock file and install/remove/update the changed nested requirements.
If people can do some further testing of this branch, it would be much appreciated.
@mcaskill I think that behaviour might have already existed in this plugin, I've noticed a few times when changing October CMS plugins that I load into a October CMS project that sometimes I'll have to run composer update twice to get it to fully cleanup the dependencies that were only included by those plugins, hence nested requirements.
I found a working version here https://github.com/TopFloorTech/composer-merge-plugin/tree/composer-2-fix
I found a working version here https://github.com/TopFloorTech/composer-merge-plugin/tree/composer-2-fix
That fork is simply a merge of this pull request without additional changes (comparison).
@reedy @bd808 what's required to get this merged?
@reedy @bd808 what's required to get this merged?
I have been trying to hand maintenance of composer-merge-plugin over to a team within the Wikimedia Foundation for several months. Unfortunately that hand off is taking far longer than I had hoped. This PR is sort of being held hostage (by me) as a forcing function to complete the transition. I will not at all block any other person with merge rights in this repo from accepting the PR and tagging a new release, but I will not be doing it personally.
@mcaskill can you merge this PR https://github.com/mcaskill/composer-merge-plugin/pull/1 to your repo
@bd808 is the Wikimedia Foundation still interested in maintaining this plugin? If we absolutely have to maintain it at @octobercms we will, given that we use it extensively but of course it would be better if it stayed with wikimedia, so long as they're actually able to maintain it.
@mcaskill can you merge this PR mcaskill#1 to your repo
I have not merged it yet because I am uncertain of its stability when it comes to extended usage as well as first install.
For example, upon first install of the plugin a secondary run of composer update
is performed which will target all packages which is might be undesired.
Also, I have not tested subsequent updates to root, nested, or merged packages.
@bd808 is the Wikimedia Foundation still interested in maintaining this plugin?
I sure hope so. :) This plugin was invented to help folks who are managing MediaWiki deployments and using Composer to provision MediaWiki Extensions. The plugin is actively used not only by many so called "third-party" deployments of MediaWiki, but also by the CI systems and some local development environments for MediaWiki at the Wikimedia Foundation.
@bd808 @reedy @mcaskill What is needed in order to push this through to completion? Do we need to put up some money to move this forward? This is actively blocking new installs of October CMS via composer when using composer 2.0.
This is actively blocking new installs of October CMS via composer when using composer 2.0.
And concrete5 CMS...
And Evolution CMS
And Drupal 8 with webform libraries
And UserFrosting...
If testing / manpower is required to get this merged, let us know too.
I am pretty sure you can all try it out and make sure it works with your respective CMSs/use cases. The sooner issues get reported the better.
Using something like this in your composer.json should let you try out @mcaskill 's fork/feature branch.
{
"repositories": [
{"type":"vcs", "url":"https://github.com/mcaskill/composer-merge-plugin"}
},
"require": {
"wikimedia/composer-merge-plugin": "dev-feature/composer-v2 as 1.5.0"
}
}
And basically replying "me too" doesn't really help.
As pointed out, there is a patch, it is being worked on... but there's some issues that have seemingly come up from later changes in the composer 2.x release cycle. Helping test the patch helps everyone, and has been said multiple times. For example, if we'd merged this based on earlier patches, and made a release, there's seemingly use cases that would have still been broken.
An option (for now) is to just document your application only supports composer 1.x. We have done that for MediaWiki. I doubt that at this stage there's many people that have to use composer 2.x; the fact that the merge-plugin doesn't work on it seems to just confirm that, as you've got an incompatible mix of software, so you can't require composer 2.x features and composer-merge-plugin as both compulsory.
It's similarly documented at https://github.com/composer/composer/issues/9329 (ie how to downgrade; and downgrading is easy) too as a way forward
I know people get upgrade-itis (plus composer does like to warn there's an upgrade available), but if you document it doesn't work, and they don't read them... You can just point them at it ;)
AIUI, composer 1.x is still supported, and presumably will be to some extent for a while
AIUI, composer 1.x is still supported, and presumably will be to some extent for a while
Emphasis on to some extent, we would really like for most people to migrate to v2 ASAP - it's bound to happen anyway and it makes everyone's life easier once the transition is complete, so might as well get it over with :) So yes we will keep supporting 1.x with critical fixes, but it's not receiving any more than that.
I'm using the patch on a few production sites and can confirm it works for October CMS projects 👍
AIUI, composer 1.x is still supported, and presumably will be to some extent for a while
Emphasis on to some extent, we would really like for most people to migrate to v2 ASAP - it's bound to happen anyway and it makes everyone's life easier once the transition is complete, so might as well get it over with :) So yes we will keep supporting 1.x with critical fixes, but it's not receiving any more than that.
Oh for sure. I'm certainly not saying never upgrade :).
But when you (composer/upstream) know some well used plugins don't work yet, but are actively being worked on (not abandoned etc)... And it's only a month or so from release, I'd hope you wouldn't be dropping the support too quickly :), at least, not until stable releases are out.
(Also, thanks for helping CR the PR 👍 )
"require": {
"wikimedia/composer-merge-plugin": "dev-feature/composer-v2 as 1.5.0",
},
"repositories": [
{
"type": "vcs",
"url": "https://github.com/mcaskill/composer-merge-plugin"
}
],
this fixed my october cms composer.json. thank you sir.
This works for Apiato. Thank you!
And basically replying "me too" doesn't really help.
As pointed out, there is a patch, it is being worked on... but there's some issues that have seemingly come up from later changes in the composer 2.x release cycle. Helping test the patch helps everyone, and has been said multiple times. For example, if we'd merged this based on earlier patches, and made a release, there's seemingly use cases that would have still been broken.
An option (for now) is to just document your application only supports composer 1.x. [...]
Where do we stand 15 days later? I get saying "me too" won't probably help, but so does having to go through many repo to add the doc warning, having to handle our support chat for people who don't read the warning and add a fix so Travis don't actually use Composer 2...
We have report of the general fix working in some project. What are the other "issues that have seemingly come up from later changes in the composer 2.x"? Can we have details on that so we can't focus testing on this element? Any other testing element we need to focus on?
This PR is sort of being held hostage (by me) as a forcing function to complete the transition.
Is that still an issue? What can we do to help if it's the case ?
See the commits added after my comment? https://github.com/wikimedia/composer-merge-plugin/pull/189#commits-pushed-05b6bb0
So I don't remember where I read this, and didn't see it again with a quick look, but I think it was a comment by macskill... Questioning if this was a bug or similar
First run of composer update
using composer 2.0 (specifically 2.0.8) and "dev-feature/composer-v2 as 1.5.0"
results in all of the dependancies brought in via extra/merge-plugin/include (which are composer.json files themselves) originally by a composer 1.x version being removed and the merge plugin being updated.
Running it again immediately after brings them all back again...
reedy@ubuntu64-web-esxi:/var/www/wiki/mediawiki/core$ php ../composer-2.0.phar update
The "wikimedia/composer-merge-plugin" plugin was skipped because it requires a Plugin API version ("^1.0") that does not match your Composer installation ("2.0.0"). You may need to run composer update with the "--no-plugins" option.
> ComposerHookHandler::onPreUpdate
Loading composer repositories with package information
Updating dependencies
Lock file operations: 0 installs, 1 update, 24 removals
- Removing beberlei/assert (v3.3.0)
- Removing brick/math (0.9.1)
- Removing christian-riesen/base32 (1.3.2)
- Removing defuse/php-encryption (v2.2.1)
- Removing fgrosse/phpasn1 (v2.2.0)
- Removing firebase/php-jwt (v5.2.0)
- Removing jakobo/hotp-php (v1.0.1)
- Removing lcobucci/jwt (3.4.1)
- Removing league/event (2.2.0)
- Removing league/oauth2-server (dev-v9.0.0-alpha a00cc3c)
- Removing league/uri (6.4.0)
- Removing league/uri-components (2.2.1)
- Removing league/uri-interfaces (2.2.0)
- Removing psr/http-factory (1.0.1)
- Removing ramsey/collection (1.1.1)
- Removing ramsey/uuid (4.1.1)
- Removing spomky-labs/base64url (v2.0.4)
- Removing spomky-labs/cbor-php (v2.0.1)
- Removing symfony/process (v5.2.0)
- Removing web-auth/cose-lib (v3.2.10)
- Removing web-auth/metadata-service (v3.2.10)
- Removing web-auth/webauthn-lib (v3.2.10)
- Removing wikimedia/css-sanitizer (v2.0.1)
- Removing wikimedia/equivset (1.4.0)
- Upgrading wikimedia/composer-merge-plugin (v1.4.1 => dev-feature/composer-v2 a8c5a89)
Writing lock file
Installing dependencies from lock file (including require-dev)
Package operations: 0 installs, 1 update, 24 removals
- Syncing wikimedia/composer-merge-plugin (dev-feature/composer-v2 a8c5a89) into cache
- Removing wikimedia/equivset (1.4.0)
- Removing wikimedia/css-sanitizer (v2.0.1)
- Removing web-auth/webauthn-lib (v3.2.10)
- Removing web-auth/metadata-service (v3.2.10)
- Removing web-auth/cose-lib (v3.2.10)
- Removing symfony/process (v5.2.0)
- Removing spomky-labs/cbor-php (v2.0.1)
- Removing spomky-labs/base64url (v2.0.4)
- Removing ramsey/uuid (4.1.1)
- Removing ramsey/collection (1.1.1)
- Removing psr/http-factory (1.0.1)
- Removing league/uri-interfaces (2.2.0)
- Removing league/uri-components (2.2.1)
- Removing league/uri (6.4.0)
- Removing league/oauth2-server (dev-v9.0.0-alpha a00cc3c)
- Removing league/event (2.2.0)
- Removing lcobucci/jwt (3.4.1)
- Removing jakobo/hotp-php (v1.0.1)
- Removing firebase/php-jwt (v5.2.0)
- Removing fgrosse/phpasn1 (v2.2.0)
- Removing defuse/php-encryption (v2.2.1)
- Removing christian-riesen/base32 (1.3.2)
- Removing brick/math (0.9.1)
- Removing beberlei/assert (v3.3.0)
- Upgrading wikimedia/composer-merge-plugin (v1.4.1 => dev-feature/composer-v2 a8c5a89): Checking out a8c5a89c60 from cache
Package phpunit/php-token-stream is abandoned, you should avoid using it. No replacement was suggested.
Generating optimized autoload files
36 packages you are using are looking for funding.
Use the `composer fund` command to find out more!
> ComposerVendorHtaccessCreator::onEvent
reedy@ubuntu64-web-esxi:/var/www/wiki/mediawiki/core$ php ../composer-2.0.phar update
> ComposerHookHandler::onPreUpdate
Loading composer repositories with package information
Updating dependencies
Lock file operations: 24 installs, 0 updates, 0 removals
- Locking beberlei/assert (v3.3.0)
- Locking brick/math (0.9.1)
- Locking christian-riesen/base32 (1.3.2)
- Locking defuse/php-encryption (v2.2.1)
- Locking fgrosse/phpasn1 (v2.2.0)
- Locking firebase/php-jwt (v5.2.0)
- Locking jakobo/hotp-php (v1.0.1)
- Locking lcobucci/jwt (3.4.1)
- Locking league/event (2.2.0)
- Locking league/oauth2-server (dev-v9.0.0-alpha a00cc3c)
- Locking league/uri (6.4.0)
- Locking league/uri-components (2.2.1)
- Locking league/uri-interfaces (2.2.0)
- Locking psr/http-factory (1.0.1)
- Locking ramsey/collection (1.1.1)
- Locking ramsey/uuid (4.1.1)
- Locking spomky-labs/base64url (v2.0.4)
- Locking spomky-labs/cbor-php (v2.0.1)
- Locking symfony/process (v5.2.0)
- Locking web-auth/cose-lib (v3.2.10)
- Locking web-auth/metadata-service (v3.2.10)
- Locking web-auth/webauthn-lib (v3.2.10)
- Locking wikimedia/css-sanitizer (v2.0.1)
- Locking wikimedia/equivset (1.4.0)
Writing lock file
Installing dependencies from lock file (including require-dev)
Package operations: 24 installs, 0 updates, 0 removals
- Syncing league/oauth2-server (dev-v9.0.0-alpha a00cc3c) into cache
- Installing brick/math (0.9.1): Extracting archive
- Installing christian-riesen/base32 (1.3.2): Extracting archive
- Installing fgrosse/phpasn1 (v2.2.0): Extracting archive
- Installing firebase/php-jwt (v5.2.0): Extracting archive
- Installing jakobo/hotp-php (v1.0.1): Extracting archive
- Installing league/event (2.2.0): Extracting archive
- Installing lcobucci/jwt (3.4.1): Extracting archive
- Installing defuse/php-encryption (v2.2.1): Extracting archive
- Installing league/oauth2-server (dev-v9.0.0-alpha a00cc3c): Cloning a00cc3c274 from cache
- Installing league/uri-interfaces (2.2.0): Extracting archive
- Installing league/uri (6.4.0): Extracting archive
- Installing league/uri-components (2.2.1): Extracting archive
- Installing ramsey/collection (1.1.1): Extracting archive
- Installing psr/http-factory (1.0.1): Extracting archive
- Installing beberlei/assert (v3.3.0): Extracting archive
- Installing web-auth/metadata-service (v3.2.10): Extracting archive
- Installing web-auth/cose-lib (v3.2.10): Extracting archive
- Installing symfony/process (v5.2.0): Extracting archive
- Installing spomky-labs/cbor-php (v2.0.1): Extracting archive
- Installing spomky-labs/base64url (v2.0.4): Extracting archive
- Installing ramsey/uuid (4.1.1): Extracting archive
- Installing web-auth/webauthn-lib (v3.2.10): Extracting archive
- Installing wikimedia/css-sanitizer (v2.0.1): Extracting archive
- Installing wikimedia/equivset (1.4.0): Extracting archive
12 package suggestions were added by new dependencies, use `composer suggest` to see details.
Package phpunit/php-token-stream is abandoned, you should avoid using it. No replacement was suggested.
Generating optimized autoload files
47 packages you are using are looking for funding.
Use the `composer fund` command to find out more!
> ComposerVendorHtaccessCreator::onEvent
reedy@ubuntu64-web-esxi:/var/www/wiki/mediawiki/core$
First run of
composer update
using composer 2.0 (specifically 2.0.8) and"dev-feature/composer-v2 as 1.5.0"
results in all of the dependancies brought in via extra/merge-plugin/include (which are composer.json files themselves) originally by a composer 1.x version being removed and the merge plugin being updated.
Good point. I did not try updating dependencies from Composer 1.0 and then again in 2.0.
Thanks for spotting this.
So what happens is in the first update there the plugin is ignored so Composer is not aware of the merged dependencies and removes them, you see this with:
The "wikimedia/composer-merge-plugin" plugin was skipped because it requires a Plugin API version ("^1.0") that does not match your Composer installation ("2.0.0"). You may need to run composer update with the "--no-plugins" option.
I think the only way you might be able to fix this is if you update the plugin first using composer 1 to a version supporting both composer 1 and 2, then running with composer 2 should not delete the merged dependencies, as the plugin will be ready for composer 2 already.
Tested this PRs on Evolution CMS 3.0 All work correct
I tried to test #189, but failed to get a working composer.json. Where exactly does this code go? I also tried using composer 1.x with "wikimedia/composer-merge-plugin": "dev-feature/composer-v2 as 1.5.0" as a requirement, and that failed also.
Root composer.json requires wikimedia/composer-merge-plugin dev-feature/composer-v2 as 1.5.0, found wikimedia/composer-merge-plugin[dev-master, dev-composer20, v0.5.0, v1.0.0, ..., 1.5.x-dev (alias of dev-master)] but it does not match the constraint.
"require": { "wikimedia/composer-merge-plugin": "dev-feature/composer-v2 as 1.5.0", }, "repositories": [ { "type": "vcs", "url": "https://github.com/mcaskill/composer-merge-plugin" } ],
You basically need to bring the code above into your composer.json
Add the repository entry, update your require/require-dev entry
No issues using this version. 👍
I installed this using Composer 2.0.8 in the root composer.json of a Drupal 9 site, and it is working correctly.
As far as installing dependencies listed in composer.libraries.json goes, it seems to work just fine with Drupal 8.9.11 and the webform module.
All I did was make the changes from the opening comment and then ran composer update --ignore-platform-reqs
.
$ composer --version
Composer version 2.0.6 2020-11-07 11:21:17
$ php --version
PHP 7.3.25-1+ubuntu20.04.1+deb.sury.org+1 (cli) (built: Dec 26 2020 10:32:51) ( NTS )
Copyright (c) 1997-2018 The PHP Group
Zend Engine v3.3.25, Copyright (c) 1998-2018 Zend Technologies
with Zend OPcache v7.3.25-1+ubuntu20.04.1+deb.sury.org+1, Copyright (c) 1999-2018, by Zend Technologies
$ composer update --ignore-platform-reqs
Gathering patches for root package.
> DrupalProject\composer\ScriptHandler::checkComposerVersion
Loading composer repositories with package information
Updating dependencies
Lock file operations: 23 installs, 0 updates, 0 removals
- Locking algolia/places (1.19.0)
- Locking choices/choices (9.0.1)
- Locking ckeditor/autogrow (4.14.1)
- Locking ckeditor/codemirror (v1.17.12)
- Locking ckeditor/fakeobjects (4.14.1)
- Locking ckeditor/image (4.14.1)
- Locking ckeditor/link (4.14.1)
- Locking codemirror/codemirror (5.53.2)
- Locking jquery/chosen (1.8.7)
- Locking jquery/geocomplete (1.7.0)
- Locking jquery/hotkeys (0.2.0)
- Locking jquery/icheck (1.0.2 )
- Locking jquery/image-picker (0.3.1)
- Locking jquery/inputmask (5.0.5)
- Locking jquery/intl-tel-input (16.1.0)
- Locking jquery/rateit (1.1.3)
- Locking jquery/select2 (4.0.13)
- Locking jquery/textcounter (0.9.0)
- Locking jquery/timepicker (1.13.14)
- Locking jquery/toggles (4.0.0)
- Locking progress-tracker/progress-tracker (1.4.0)
- Locking signature_pad/signature_pad (2.3.0)
- Locking svg-pan-zoom/svg-pan-zoom (3.6.1)
Writing lock file
Installing dependencies from lock file (including require-dev)
Package operations: 23 installs, 0 updates, 0 removals
- Downloading codemirror/codemirror (5.53.2)
Gathering patches for root package.
Gathering patches for dependencies. This might take a minute.
- Installing algolia/places (1.19.0): Extracting archive
- Installing choices/choices (9.0.1): Extracting archive
- Installing ckeditor/autogrow (4.14.1): Extracting archive
- Installing ckeditor/codemirror (v1.17.12): Extracting archive
- Installing ckeditor/fakeobjects (4.14.1): Extracting archive
- Installing ckeditor/image (4.14.1): Extracting archive
- Installing ckeditor/link (4.14.1): Extracting archive
- Installing codemirror/codemirror (5.53.2): Extracting archive
- Installing jquery/chosen (1.8.7): Extracting archive
- Installing jquery/geocomplete (1.7.0): Extracting archive
- Installing jquery/hotkeys (0.2.0): Extracting archive
- Installing jquery/icheck (1.0.2 ): Extracting archive
- Installing jquery/image-picker (0.3.1): Extracting archive
- Installing jquery/inputmask (5.0.5): Extracting archive
- Installing jquery/intl-tel-input (16.1.0): Extracting archive
- Installing jquery/rateit (1.1.3): Extracting archive
- Installing jquery/select2 (4.0.13): Extracting archive
- Installing jquery/textcounter (0.9.0): Extracting archive
- Installing jquery/timepicker (1.13.14): Extracting archive
- Installing jquery/toggles (4.0.0): Extracting archive
- Installing progress-tracker/progress-tracker (1.4.0): Extracting archive
- Installing signature_pad/signature_pad (2.3.0): Extracting archive
- Installing svg-pan-zoom/svg-pan-zoom (3.6.1): Extracting archive
Package container-interop/container-interop is abandoned, you should avoid using it. Use psr/container instead.
Package doctrine/reflection is abandoned, you should avoid using it. Use roave/better-reflection instead.
Package flow/jsonpath is abandoned, you should avoid using it. Use softcreatr/jsonpath instead.
Package phpunit/php-token-stream is abandoned, you should avoid using it. No replacement was suggested.
Generating autoload files
59 packages you are using are looking for funding.
Use the `composer fund` command to find out more!
> DrupalProject\composer\ScriptHandler::createRequiredFiles
I'm having an issue with the post install run of update in my CI run. Because the CI is always installing it's artifact for the first time, it triggers isFirstInstall()
and then post-install runs composer update again, which is unnecessary since my lock file already has all the merged dependencies. This can cause my lock file on my repo to not be the same as the lock that the CI's artifact builds and (luckily) fails my pipeline.
Latest Update 2021-01-25 14:25 EST
Notes:
See comment.
See comment.
See comment.
composer update
again.See comment.
isFirstInstall()
on Composer v2. Listening only topost-update-cmd
instead ofpost-install-cmd
might be more sensible. See comment and followup.How to test:
Tasks:
See comment #1, comment #2, comment #3.
MultiConstraint
to latest version of composer/semver.See comment.
Factory::getLockFile()
does not exist in Composer 1.See comment.
Replaces #187, #185, as fix for #184 (as per composer/composer#8726)
I've tested using the example and the unit tests and it works in Composer v1 and v2.
This alternative proposal forgoes
PRE_DEPENDENCIES_SOLVING
entirely to avoid over-complicating the codebase and streamline the plugin's merge logic.The issue with the previous attempts (as well as attempts on other plugins) stems from a miscommunication from the Composer team of the major difference in how v1 and v2 resolve and install dependencies.
Back to my proposal.
Currently, the use of
PRE_DEPENDENCIES_SOLVING
in the plugin is used to inject duplicate requirements (usually with a different version constraints) into the solver (while distinguishing betweenrequire
andrequire-dev
).What I propose replaces the duplicate links tracking in
ExtraPackage
by back porting Composer 2's new staticMultiConstraint::create()
method which can be used to resolve complex-constraints early on. In turn, this makes the need forPRE_DEPENDENCIES_SOLVING
obsolete.I hope this PR will, at the very least, help to figure out how to support Composer v2.