When trying to install this module using
composer require drupal/drupalmoduleupgrader
I get this error:
Your requirements could not be resolved to an installable set of packages.
Problem 1
- Installation request for phpdocumentor/reflection-docblock (locked at 4.3.1) -> satisfiable by phpdocumentor/reflection-docblock[4.3.1].
- drupal/drupalmoduleupgrader 1.x-dev requires grom358/pharborist dev-master -> satisfiable by grom358/pharborist[dev-master].
- drupal/drupalmoduleupgrader 1.4.0 requires grom358/pharborist dev-master -> satisfiable by grom358/pharborist[dev-master].
- Conclusion: don't install grom358/pharborist dev-master
- Installation request for drupal/drupalmoduleupgrader ^1.4 -> satisfiable by drupal/drupalmoduleupgrader[1.x-dev, 1.4.0].
Installation failed, reverting ./composer.json to its original content.
Using Drush gives me the "drush dl deprecated" message. Is there something I'm missing?
Comments
Comment #2
mmjvb commentedAs shown above there is no problem with this module. Changed the category to a support request. Troubleshooting composer starts with a selfupdate. Make sure you use a recent version of composer. The information you report suggest an older version in use.
It appears that phpdocumentor/reflection-docblock is blocking, suggest to whitelist it on the update shown above. It mentions to be locked at 4.3.1 while 2.0.5 is acceptable for my environment. The whitelisting should allow it to downgrade.
This is why you should require with --no-update, so you can use update with --dry-run. You could try to update with --with-dependencies to allow the downgrade or even --with-all-dependencies.
Not convinced grom358/pharborist is an issue, hence the selfupdate of composer.
Comment #3
tonytheferg commentedI get the same error. This is the only module I have seen this error with Composer.
Composer version 1.8.6. i have installed a lot of modules with this version, I would hesitate just updating composer for the sake of one module that is not cooperating. changing this back to bug report.
Comment #4
tonytheferg commentedComment #5
mmjvb commentedPlease refrain from changing it to a bug report. As mentioned it is a support request. This is what composer does, nothing to do with this module. You have conflicting requirements that you need to solve. Provided suggestions how to achieve this, please respond to those instead of simple repeating the report.
- Did you whitelist?
- Did you use --with-dependencies or --with-all-dependencies
In your case there is no need for selfupdate, composer 1.8.6 is recent enough. Despite that it is always advised to do, due to improvements and bg fixes.
Comment #6
mmjvb commentedComment #7
tonytheferg commentedNo, I installed using the command provided. Maybe that command should be changed if it's not sufficient. I thought composer grabbed dependant libraries by default. That's how it's functioned on every other successful module requirement anyway.
Comment #8
mmjvb commentedWhich command do you mean? There is no need to change the command provided, it gives an idea what to do and works in normal circumstances. Your need to adjust for your circumstances.
It is evident you have a poor understanding of composer. Yes, it does try to resolve your requirements and reports it when you have conflicts. Obviously, it continues when there are no conflicts. Having conflicts and resolving them should be considered normal practice. Just because you haven't experienced conflicts before doesn't mean it is doing something wrong. Resolving conflicts is part of your job, composer just reports them.
Comment #9
tonytheferg commentedThe require command on the module page. You are correct, i do have a poor understanding of composer. :) I am not sure if when you say "--with-dependencies" if you mean
composer require drupal/drupalmoduleupgrader --update-with-dependencies, as --with-dependencies is not a valid require command from what i've found? This is the first module I have encountered where composer doesn't get the required dependencies.Comment #10
mmjvb commentedNo, don't mean that. The --with-dependencies is for the update. The --update-with-dependencies is for the require.
Recommend the --no-update on the require to make sure your requirements are updated in the compser.json. Your changed requirements can be resolved with the update --dry-run to find out which modules to whitelist. Possible used with --with-dependencies or even --with-all-dependencies depending on the feedback you get. The --dry-run is to know up front what it wants to do. Running the same command without the --dry-run once you are happy. In your case, earlier versions of the requirements resolved in a solution no longer available due to the change in requirements. That is why it reports what is locked at certain version. That version is no longer availble due to change in requirements, hence the whitelisting to allow it downgrading.
Some people suggest not to whitelist and use the generic form of update without mentioning any module. Advise against that due to the default behavior of updating anything that can be updated. I don't like that part, only want updates to modules I allow updating. Unfortunately, there is no alternative to whitelisting, currently.
As far as poor understanding of composer, you are not alone. Remember, it wasn't meant for site builders. It is a tool for developers of php code.
Comment #11
tonytheferg commentedAre you a maintainer of the module?
Also I realized this is for the dev version, where I am getting the errors with 1.4. I don't think the conflict is with my environment, I think the conflict is between the module and composer. I might do a fresh install of the Drupal composer project and only add that module to verify the bug. Thanks for your time!
Comment #12
mmjvb commentedNo, not the maintainer of this module.
This support request is about the module, not a specific version. The conflict is in your environment. Already explained why.
See for yourself:
Comment #13
mmjvb commentedcomposer show -t drupal/drupalmoduleupgrader
Comment #14
mmjvb commentedYour environment should show dependency allowing 4.3.1 because it mentions it is locked to that version. The command above should reveal which package that is. Whitelisting reflection-docblock or the package requiring it should resolve your issue.
Obviously, only when that package also allows for 2.0.*. Otherwise you have an unresolvable conflict. That means you need to address it with those packages that require reflection-dockblock: grom358/pharborist and the package allowing 4.3.1.
Comment #15
mmjvb commentedIt looks like grom358/pharborist is no longer maintained. You could introduce a package repository for it allowing 4.3.1 of reflection-docblock. That assumes pharborist is able to use more recent versions of reflection-docblock.
Obviously, only when you need it together. A separate instance for drupalmoduleupgrader is probably less work.
Comment #16
omkar06 commentedMarking this ticket to Active as still facing issue to install module using composer.
I tried this module to install on the latest version of Drupal core i.e. 8.7.8 and As well as Lightning. But in both setups, I am getting below dependency error.
Comment #17
nathaniel commentedI had a similar issue. Adding
"drupal/drupalmoduleupgrader": "1.x-dev"to composer.json require manually then runningcomposer updateseemed to work.Comment #18
adam.bauer commented# 17 worked for me, Thanks Nathaniel
Comment #19
ultimikeIt appears that the current stable (8.x-1.5) and -dev version (18 Sept 2019) of this project are not compatible with the Drupal Composer/Drupal Project template for Drupal 8.7.* due to a dependency conflict. I tried with both a webflo/drupal-core-strict and webflo/drupal-core-require-dev versions of the template.
That being said, if you really want to use this project, you can do what I did and create a Drupal 8.2 (I'm not sure exactly which minor versions of Drupal core will work - I just randomly tried Drupal 8.2 and it was fine) site to run this project, then transfer the upgraded module to your actual project site.
I suspect that the disconnect happened going from Drupal core 8.6 -> 8.7. I think that the dependencies for this project need to be updated, but I'm not 100% sure.
-mike
Comment #20
chipway commented#17 + composer update --with-dependencies installation worked for me on a Drupal 8.7.10 installed some time ago with https://github.com/drupal-composer/drupal-project/ Composer/Drupal Project template.
composer update --with-dependencies> DrupalProject\composer\ScriptHandler::checkComposerVersion
Loading composer repositories with package information
Updating dependencies (including require-dev)
Package operations: 3 installs, 1 update, 2 removals
- Removing phpdocumentor/type-resolver (1.0.1)
- Removing phpdocumentor/reflection-common (2.0.0)
- Installing cebe/markdown (1.0.3): Downloading (100%)
- Downgrading phpdocumentor/reflection-docblock (4.3.2 => 2.0.5): Loading from cache
- Installing grom358/pharborist (dev-master 0db9e51): Cloning 0db9e51299 from cache
- Installing drupal/drupalmoduleupgrader (1.5.0): Downloading (100%)
Comment #21
schillerm commented#17 worked for me!
Comment #22
drupal.ninja03 commentedThanks @nathaniel. #17 worked for me.
Comment #23
binnythomas commentedThanks @Nathaniel #17 worked for me as well.
Comment #24
lennart commented#17 does NOT seems to work with drupal 9.0.7
Nor does it work without that change with neither drupalmoduleupgrader 8.x-1.5 nor 8.x-1.x-dev
with
drupal/recommended-project
with these in require:
composer/installers: ^1.9,
drupal/core-composer-scaffold: ^9,
drupal/core-project-message: ^9,
drupal/core-recommended: ^9,
Comment #25
gisleI had a similar problem ("Your requirements could not be resolved to an installable set of packages") on one of my sites:
Environment:
For what it is worth, the thermonuclear option worked for me. i.e.:
However, in #3158087: "Command is not defined" ...after install. Drupal 8.9, Drush 9.7.2 mmjvb advice against doing this (I don't grok composer and don't understand why this is bad).
Comment #26
goldI would like to suggest that this does get elevated to a Bug Report. However, the actual bug resides in a requirement of a module this one requires.
I just submitted a patch on issue #3180085 and the patch test pipeline failed at the
composer requirestep with this same error.c.f., https://www.drupal.org/pift-ci-job/1869633
At this point I would be inclined to think that this isn't a conflict in the environment @TonyTheFerg has, as suggested at comment #12.
Looking at composer.json for this module it is including the following;
"grom358/pharborist": "dev-master"Using dev-master here is incredibly unstable and should likely be updated to a known state. However, in this case this module has not been updated since 2015 so that isn't likely to be the source of the issue.
Looking at the actual problem:
grom358/pharboristrequires"phpdocumentor/reflection-docblock": "2.0.*".So, what else depends on
phpdocumentor/reflection-docblock?At this point we can see that
phpspec/prophecyalso requiresphpdocumentor/reflection-docblockand has a much larger range of viable versions to select from. In turn, if we callcomposer depends phpspec/prophecywe can see that this is installed as part of the initial Drupal install.From Problem 1 above we can see that
phpdocumentor/reflection-docblockis "locked at 4.3.4". This will be because 4.3.4 met the requirements at the time. The later addition ofdrupalmoduleupgraderand it's subsequent requirements is what actually caused the issue.This also explains why adding the module to the composer.json and deleting the vendor directory works as composer can work out a version of
phpdocumentor/reflection-docblockthat satisfies all requirements.So, this is a Bug Report and it is not related to any individual developers environment.
The solution is to either replace
grom358/pharboristor resolve the issue there.Another thing to consider is that this is a utility module and unlikely to ever be deployed to other environments. An instruction in the README explaining the versioning issue and a simple
rm -rf /path/to/vendordoesn't feel that bad as a work around.Comment #27
mmjvb commentedNo, still a support request because your circumstances involve the additional requirement which resolves into a conflict when changing requirements. Happens all the time! You just need to whitelist phpspec/prophecy and any other package that may cause a conflict.
In the end there might be no way to resolve conflict free, then it is time to request changes to package version constraints. Obviously, with the package involved, not the packages that use it. Welcome to dependency management !
Comment #28
joseph.olstad#3183927: Fix automated tests, broken since November 4th 2020
Comment #29
joseph.olstadComment #30
jcnventuraThanks for the analysis here people. Let me try something...
Comment #32
jcnventuraOK. My experiment worked. I've switched over to my own fork of grom358/pharborist, which I maintain and can easily figure out any further issues.
Note that I haven't been actively using this module for some time (already upgraded most of my D7 stuff over to D8 and now D9, so I'm no longer actively using this module.. That being said, I need people to test these changes, and RTBC whatever can be RTBCd, please.
Comment #33
gislejcnventura,
thanks for fixing this! I still very much rely in this.
Comment #34
joseph.olstadgreat work jcnventura! Thanks!
Comment #35
joseph.olstad8.x is fixed
Openned a new issue for 9.x