Come together with the global Drupal community in Rotterdam, 28 Sept – 1 Oct 2026. Sessions, contribution, connection, and Early Bird savings until 8 June.
By ludootje on
Composer, * sigh *.
I tried to install the promising Entity Pager module. It comes with this install instruction for Composer, which I used:
composer require drupal/entity_pager:^1.0@RCActually, there was a single quote before drupal and after RC, but past experience showed me that those quotes don't work with my setup. Anyway, a couple of seconds later, I get this:
Root composer.json requires drupal/entity_pager 1.0@RC, found drupal/entity_pager[dev-1.x, dev-2.0.x, 1.0.0-alpha1, ..., 1.x-dev (alias of dev-1.x), 2.0.x-dev (alias of dev-2.0.x)] but it does not match the constraint.Okay, once again: * sigh *
Anyway, is there a kind soul who could help me with the correct Composer instruction?
Comments
Generally you shouldn't add a
Generally you shouldn't add a version constraint when adding packages. Let you system decide which version it will do.
Sometimes you need to actually tell it to look for any compatible version:
Contact me to contract me for D7 -> D10/11 migrations.
Recommendations did not do the trick
Thanks, Jaypan, but your two recommendations did not lead to a good result:
led to
And your second recommendation,
led to this tremendously informative error message:
Are there any other solutions?
Allow "dev" versions
If you want to install a dev-version, you must edit your project's "composer.json" to allow this:
Change this line:
to:
Edit: Happy to hear it worked! However, I've removed the explanation, as it turned out to be incorrect. Thanks to mmjvb for correcting me.
- gisle
Thanks, Gisle!
Your advice did it: I changed that line in composer.json, and the thing installed without a hiccup. Thanks, but jokes like this (and others which I experienced in the recent past) Don't convince me one bit that the almost compulsory (or at least widely / wildly advised) use of Composer is "a dream come true".
But for my issue: thank you both, Jaypan and Gisle, I think it's solved.
Both of you are missing the point
Your environment doesn't recognize the RC releases that are there and match requirement!
So, bad idea to change minimum-stability, use @RC on your constraint or wait for the module to reach Stable.
A bit harsh?
I think it is a bit harsh to say I'm "missing the point".
What does that mean? Is it possible to set a "RC" constraint without changing "minimum-stability? I am still trying to learn about composer, but I not able to understand the quoted sentence.
If you meant better to use "RC" instead of "dev" an an option for "minimum-stability", I agree. It would have matched the use case better than "dev". But I answered from memory with something I knew would work, and didn't pause to look it up in the documentation.
Or do I totally misunderstand your criticism? If that is the case, can you be so kind and spell out the "point" I'm missing?
- gisle
The missing point is about the constraint
not the minimum stability. Yes, you can also set minimum stability to RC, that still leaves the fact those releases are not recognized in the output.
As you can see from the code I provided there is nothing wrong with the statement itself. It installs the rc release. Again, no idea why his environment doesn't recognize those releases.
I once were in your shoes
If you're able to locate my rants in this forum a few years back, you'll see that I was extremely annoyed about having to use composer.
It has grown on me since then. As mmjvb says: It stops you from doing stupid things to your code base. However, learning to grok what it tells you takes some time, and that learning curve is indeed frustrating. Just keep at it. It will only get better.
- gisle
Thanks for having done the ranting for me, Gisle :-)
Thanks for the sound advice. I will give myself a couple more years to have an inkling of an idea why Composer exists the way it exists. In the mean time, however, I will also long for yesteryear, when installing a new module was a matter of locating it (drupal.org, as it is now), downloading, unzipping, copying and activating it. Sometimes it didn't work. Okay. I suppose Composer is something useful for some level of advanced fulltime programmers to tackle some issues in some situations. But I don't think I belong to that group.
Thanks guys, and keep on ranting :-)
Your advice did it: I changed
This is a feature to ensure that sites meet minimum standards of code. While you may be ok with having dev, alpha, beta, and/or release candidate modules in your code, many projects that require security clearance, for large corporations and government, have requirements that only stable releases of modules be used on a site, as these are covered by Drupal's security advisory. Setting the flag to 'stable' in composer.json sets this standard, and prevents developers from committing insecure code, which in some cases could lead to said developer being fired. Proper development means removing chances for human error. Prior to Composer integration, each module had to be checked to ensure it had a full release, and there was nothing preventing a developer from accidentally committing an unstable release. With Composer, this limitation can be set, making for better managed projects.
Understanding this was a hassle for you, but it appears you are trying to use Composer without doing tutorials on it, or reading books on it first. Which is fair, as it is how some people learn. And actually, it's how you just learned. People who take the time to do some studying on Composer will be less likely to run into this same issue, as it should be covered in Composer tutorials. For you to decide that Composer does not have value, simply because it had a feature you didn't understand, due to not studying Composer before using it, isn't really the right place to be coming from when making proclamations on whether or not Composer has value overall.
Contact me to contract me for D7 -> D10/11 migrations.
Thanks for your comments, Jaypan.
I guess you are very right in stating that I was a wee bit too enthusiastic in my negative ideas about Composer. I suppose it was the anger/disappointment of the moment. To be sure: I didn't mean to aggravate those who studied and know Composer. I admire their efforts and am all too happy that they are willing to share that with ignorami like me.
One remark, though: the way Composer communicates with its users, the feedback it gives, especially to beginning users, is, in my (humbled) opinion, not "stable" or a "release candidate", but rather an "alpha", tops. Its feedback has, shall we say, room for improvement, esp. from a communicator's point of view. Programs should be technically sound, but their interaction with the world should be in order too. It's a pity - not only afflicting Composer, but also many Drupal modules. My point: much, much, much more attention should be given to user communication. For me, a "stable" program with poor feedback or documentation should be considered "alpha".
One question: who actually decides whether a piece of software is "stable", "RC", "dev", "beta", "alpha", "sandbox", ....? Is that some evaluation committee within the Composer world? Or is it, as I assume, the developers? Just wondering: who decides about these things? If it's still the developer, then in what sense is Composer a guarantee of the software's reliability?
And, needless to say, thanks for your interest!
The developer of each module
The developer of each module decides the version, however the Drupal security team will only cover modules with full releases, not with dev, alpha, beta, or RC releases.
It's not. It's still up to the developer to test and verify. But that's not really the point - the point is that many clients will not allow code that is not covered by security policies. It's not a guarantee that code is quality, but it's an assurance that it's not uncovered.
Contact me to contract me for D7 -> D10/11 migrations.
Why do you think there is something wrong with the statement
By now, it should be evident that it is your environment that is not properly set up causing these kind of problems.
You could try alternate syntax for your environment:
composer require drupal/entity_pager ^1.0@RC
composer require drupal/entity_pager=^1.0@RC
Don't like the formats with : or =, prefer package and constraint as separate values. Works in most environments, you might need to add double quotes around constraint to prevent the shell interpretation of special characters.
Whether you need to provide a constraint is depending on the minimum-stability for your project and the availability of Stable releases. Obviously, projects only allowing Stable releases can't match requirements when package not having a Stable release yet.
Not matching requirements is something you should expect, as you tell composer to update with the scope of the package. When trying to update it will calculate requirements, no surprise when requirements can't be met !
That is the whole purpose of Composer, it stops you from doing stupid things to your code base. No idea why your environment doesn't see the versions available. You might check your environment for why you have outdated information. Are you sure the information is retrieved?
You have me
OK, I see that even if I have minimum stability set to "stable", composer is still happy to install it on my staging site:
My question is: Why? Shouldn't composer complain about it not fulfilling the "stable" root requirement?
I obviously still has some way to go before I grok composer.
- gisle
Exactly what I reported.
Which is what it is supposed to do as well. So, works as expected. The @RC on the version constraint on the require statement tells composer to allow for non-stable releases as of RC. Could have been @beta to allow for beta and RC's. That allowance is for the particular package the constraint applies on, not any other package involved in the project. That is what minimum-stability is for, unless overridden by particular version constraints.
There is no such thing as a root "stable" requirement. It is a default setting when no setting is provided with the package. So, no it shouldn't complain as the stability requested is provided on the package constraint.
Just for the record, it took quite some time and effort to persuade to go for Stable releases in the project templates. So, in normal circumstances it is a bad idea to have minimum stability set in a Drupal project. You should only allow for non-stable releases for explicitly mentioned packages in your project. Remove those requirements as soon as Stable releases are available.
I wish I could contribute
I wish I could contribute something to your discussion, but I can't. I saw a composer install line on Drupal.org. I tried it, and it failed. That's all. Maybe, as mmjvb suggests, there is something wrong with my "environment", although I have No idea what that means. I have a fairly recent computer, an up to date Windows, a recent Wamp stack and the most recent Drupal. If Composer wants more, okay, but then I expect any decently finished program to tell me in non-Bulgarian what it is looking for.
The main thing, however: thanks everyone for their help.
Could you provide the output of
composer show -a drupal/entity_pager|grep versions
Grep is not present in my Windows
Hi mmjvb, I don't have grep (running WIndows, not Linux). So ! I took the first part of your command line and ">>" it to a text file. This is what the text file says:
Thanks for taking interest!
Guess that this is the current situation after doing things
you shouldn't have. That does mean it now recognizes the rc releases as it claims to be installed.
Have no explanation for first time not recognizing and later seeing those releases. Nothing to do with the commands used. The only thing I can think of is stale information and not getting up-to-date information from the repository (facade).
Reverting to the original situation suspect the require statement to execute as expected. The command show should have been executed when the require statement gave you that output. The error told you there were no RC releases which is incorrect as there were. A `composer clear cache` could have cured the situation. Looks like the correct information is available now, the question is for how long!
Learned something today
Found this section of the docs: Stability Constraints. It says:
I.e. a stability-flag given as a CLI constraint overrides the default setting in "composer.json" – and using such a flag is better practice than downgrading the default setting.
I didn't know that before this exchange. Thanks again mmjvb.
- gisle
I also did not know this. It
I also did not know this. It's a good best practice to know, thank you mmjvb.
Contact me to contract me for D7 -> D10/11 migrations.
To put in the right context
The stability flags apply for primary requirements only and for constraints only.
So, when one of your dependencies has an requirement on the alpha of a package, that alpha is only considered when allowed by primary requirement.