Requirements error says 'but it conflicts with another require' without saying what the problem actually is #9393
Comments
|
If you can, please check with #9360 applied to see if it fixes it. It hopefully does. |
|
I cloned composer from source, added https://github.com/naderman/composer.git as an origin and checked out the branch for #9360, Using the bin/composer from the git clone, I tried the command in my project again. I still get: |
|
Ok, might be another bug of the same kind then /cc @naderman @joachim-n just to get you out of your pickle here, have you tried a full |
|
The simple workaround here should be to run the update command with drupal/drupal added as well, which means running require without an update first and then manually updating: |
|
I did: same result as before. I then tried: and that worked!!! Thanks! |
|
It also works from scratch if I add |
|
I can't repro this anymore with the latest snapshot, unsure if something changed in the package landscape or if we did actually fix the issue, but anyway closing. |
|
Problem 1 |
|
composer.json |
|
Remove the lock file to get more sense |
|
@jrobens I am not sure what command you are running, when I run an install I get this which clearly explains the lock file is outdated and incompatible with the composer.json requirements: |
|
Sorry, should have put the commands in. The process is building up the composer file with --no-update and then trying to run. composer require 'drupal/core-recommended:^10' 'drupal/core-composer-scaffold:^10' 'drupal/core-project-message:^10' --no-update Then |
|
Yeah sorry I have no clue what's going on there. It's quite a pain as I cannot easily navigate the drupal packages' dependencies as with those that are on packagist.org.. But from what I gather the issue is that drupal/core_event_dispatcher requires drupal/core ^9.3, and drupal/core-recommended requires drupal/core ^10, so that's the conflict. I don't know why it does not show this in the partial update though, that is very odd, but at least doing a full update shows you the problem. This happens somehow with complex setups like core-recommended which add indirection. If you change the require to drupal/core ^10 instead of core-recommended then it works. So that might allow us to build a smaller repro case to try and understand this.. |
|
Ok I got this far: Using these files (rename .lock.json to .lock) composer.json So it seems the pool optimizer is causing this issue somehow (cc @Toflar) but I haven't gotten to the bottom of it. |
|
Bah, debugging this is super time-consuming. But here's what I've found out so far (gotta stop for today):
So seems to be related to the locked packages logic. |
|
cc @driskell as it's a drupal issue maybe you'll have an easier time reasoning about this.. I am so unfamiliar with the dependencies that it does not help :) |
|
Usually when I see this I run When I use the files from #9393 (comment) along with So I then run So here we can see that the following Drupal modules in the lock file are not marked compatible with Drupal 10 so it won't be allowed to be installed: Checking those, I manually removed from lock file to get past but maybe I could've just added to the update command. Adding the other packages that are locked to incompatible versions, I then find below: So we check that one: So yeh repeating a few times we find a few more things in lock that are not compatible, not in the composer.json but in the lock file: This then works. So it's possible it's related to when filtering the pool by the locked but not-being-updated packages, it's not accounting for something that is potentially going to be removed and therefore allow other packages to install. 😬 Separate note, the drush/drush originally included consolidation/log but then removed it in later version - adding drush/drush to the update wasn't enough - clearly it didn't add it to the pool but it being locked meant it restricted the pool and broke it - and I had to add consolidation/log to the update - this then unlocks it, stops it filtering the pool, and then it subsequently removes it after drush/drush update is chosen |
|
#11766 here are my thoughts. It should fix the problem described by @jrobens but it will revert the logic introduced by @driskell 🙈 I guess it's better to forgo an optimization in favor of a bugfix but I understand that the additional optimization step was quite important to the Drupal community as well - so let's see what we can do together 😊 |
|
Okay, managed to debug exactly on what's happening after way too many hours 😅 Here's the exact reason on what's happening in the case described by @Seldaek in #9393 (comment):
The problem is that This exact case was actually sort of considered in the However, this doesn't work properly because So the bug happens because the So long story short: The current optimization step for locked packages is flawed because it is built on top of false assumptions. I tried building a test case for that but I failed. My brain capacity is not sufficient to conjure some up some test case representing the situation that I described here but I hope it helps somebody else to create such a test file 😅 |
|
@naderman we might need your brain for the test 😉 |
|
Or well, actually I don't think we need a test, really. I think we have to remove the optimization step. |
|
@Toflar Definitely think we need a test case for this to avoid making this sort of mistake again in the future. But I don't think I'll have time for that before mid-January. |
|
Okay, I've managed to extract the exact case we're encountering into a test 🥳 See #11772 - I've kept the exact package names and versions for easier reference. |
My
composer.json:{ "name": "drupal/git-clone-project", "description": "TODO", "type": "project", "license": "GPL-2.0-or-later", "homepage": "https://www.drupal.org/project/drupal", "support": { "docs": "https://www.drupal.org/docs/user_guide/en/index.html", "chat": "https://www.drupal.org/node/314178" }, "repositories": [ { "type": "path", "url": "repos/drupal", "options": { "symlink": true } }, { "type": "path", "url": "repos/drupal/core" }, { "type": "path", "url": "repos/drupal/composer/Plugin/ProjectMessage" }, { "type": "path", "url": "repos/drupal/composer/Plugin/VendorHardening" }, { "type": "composer", "url": "https://packages.drupal.org/8" } ], "require": { "composer/installers": "^1.9", "drupal/core-composer-scaffold": "^8.9", "drupal/drupal": "*", "drush/drush": "^10.3", "symfony/var-dumper": "^5.1" }, "minimum-stability": "dev", "prefer-stable": true, "config": { "sort-packages": true }, "extra": { "drupal-scaffold": { "locations": { "web-root": "web/" } }, "installer-paths": { "web/core": [ "type:drupal-core" ], "web/libraries/{$name}": [ "type:drupal-library" ], "web/modules/contrib/{$name}": [ "type:drupal-module" ], "web/profiles/contrib/{$name}": [ "type:drupal-profile" ], "web/themes/contrib/{$name}": [ "type:drupal-theme" ], "drush/Commands/contrib/{$name}": [ "type:drupal-drush" ], "web/modules/custom/{$name}": [ "type:drupal-custom-module" ], "web/themes/custom/{$name}": [ "type:drupal-custom-theme" ] } } }Additionally need to do the following in the project folder before installing with Composer:
Output of
composer diagnose:When I run this command:
I get the following output:
And I expected this to happen:
I need to be told what the 'another require' actually is, otherwise I can't understand or fix the problem.
The text was updated successfully, but these errors were encountered: