[RuntimeException]
Could not load package drupal/superfish in https://packages.drupal.org/8: [UnexpectedValueException] Could not parse version constraint ^1.1.*: Invalid version string "^1.1.*"

This error just started, looks like composer is having trouble loading the package from drupal packagist.

Comments

Lowell created an issue. See original summary.

james.williams’s picture

james.williams CreditAttribution: james.williams at ComputerMinds commented
Priority: Normal » Major

This commit: http://cgit.drupalcode.org/superfish/commit/?id=3ea2b9ba297c2549456dc6e6... has introduced this bug. Any project using this package cannot be updated - please fix ASAP!

For now, as a workaround, the package has to be manually added to anyone's composer.json files as a repo, which is not a good solution, at all.

mroycroft’s picture

mroycroft CreditAttribution: mroycroft at Workday, Inc. commented

Workaround doesn't work, unless I did something wrong; here's the entry I put in for repositories:

    {
      "type": "vcs",
      "url": "https://github.com/drupalprojects/superfish.git"
    },

Can't update composer with superfish installed, going to bump this up to critical.

mroycroft’s picture

mroycroft CreditAttribution: mroycroft at Workday, Inc. commented
Priority: Major » Critical
Jonah Fenn’s picture

Jonah Fenn CreditAttribution: Jonah Fenn commented

I'm running into this issue as well.

mroycroft’s picture

mroycroft CreditAttribution: mroycroft at Workday, Inc. commented

As mentioned, this is the problematic composer.json syntax:

"oomphinc/composer-installers-extender": "^1.1.*"

It's not clear what's trying to be accomplished, but both ^ and * cannot be used in this way.

Lowell’s picture

Lowell CreditAttribution: Lowell as a volunteer commented

Here's the workaround I'm using, not for everyone.

Deleted the superfish requirement from my composer.json
drush dl superfish

Will simply add require superfish when it is fixed

therobyouknow’s picture

therobyouknow CreditAttribution: therobyouknow commented

Comment #2 is useful - it appears to be referring to a change to the composer.json within the superfish module itself, that caused the issue.

One would wonder if it is possible to define a specific earlier version of the superfish module in the overall composer.json - i.e. one that does not have the change in comment #2 to the composer.json within the module itself.

Thoughts?

james.williams’s picture

james.williams CreditAttribution: james.williams at ComputerMinds commented

I believe that composer reads the current version of composer.json in HEAD of the default branch (I could be wrong), and so you have to 'override' it by specifying a composer repository for the package. So a bit like what was tried in comment 3, but it would need to be before the drupal packagist repo, and needs much more details (e.g. branch to use, dependencies, type of package, etc) - but exactly what, I don't know, that's where I got stuck.

If there's another way, then great!

So, a note the module maintainer, mehrpadin: please refrain from testing changes to composer.json by committing them to the public repo, as it can break everyone's projects that are using your module!!

therobyouknow’s picture

therobyouknow CreditAttribution: therobyouknow commented

Thanks james.williams

Based on my previous comment in #8 the solution I am working through now that appears to be working is as follows:
- in the overall Drupal composer.json in docroot, remove the line: "minimum-stability": "dev",
- in the same composer.json as above, find the entry for drupal/superfish and define a specific version - i.e. the latest non-dev version i.e. 8.1.0-rc6 - and replace that line with "drupal/superfish": "8.1.0-rc6",

then run composer update

Removing "minimum-stability": "dev", makes sure that composer does use the specific version, as with this line present it seems composer ignores it.

The addition of "oomphinc/composer-installers-extender": "^1.1.*" has been introduced in the local composer.json file in superfish, in 8.1.0-rc6 it is not present so the problem will not occur with that.

james.williams’s picture

james.williams CreditAttribution: james.williams at ComputerMinds commented

Ah, interesting - thanks @therobyouknow. I've got "minimum-stability": "dev", so that'll be why I'm experiencing the issue then. Thanks!

Still not good for those of us that do actually want to use "minimum-stability": "dev"!

therobyouknow’s picture

therobyouknow CreditAttribution: therobyouknow commented

Thanks James - I would say that if dev versions of certain modules are needed then the dev version can be specified for those modules in the composer.json.

james.williams’s picture

james.williams CreditAttribution: james.williams at ComputerMinds commented

Unfortunately not: https://getcomposer.org/doc/articles/troubleshooting.md#i-have-locked-a-...

Lowell’s picture

Lowell CreditAttribution: Lowell as a volunteer commented

Honestly, I could not be more grateful for issues like this.

Thanks to this problem, I have now finally investigated and experimented with both the "minimum-stability": "dev" and the require syntax. Now I know what the ^ and ~ are for and how I might want to use them in a Drupal context.

Unfortunately I have not come up with a "composer" workaround for this ^1.1.* glitch, but I have learned more about composer :)

I use several dev modules. "minimum-stability": "dev" allows me to require a "^1.0" for example, it will get the highest number version if it exists in roughly this order. 1.2, 1.1, 1.0, 1.x-rc, 1.x-beta, 1.x-alpha, 1.x-dev. The difference with the "~1.0" is that it will not get anything higher that the 1.0 so it will not get the 1.2 or 1.1, or anything higher.

Hopefully I got these definitions and usages correct :)

james.williams’s picture

james.williams CreditAttribution: james.williams at ComputerMinds commented

@Lowell, what you've said about the version constraints doesn't quite line up with composer's documentation - you may like to read https://getcomposer.org/doc/articles/versions.md#next-significant-releas... (for example, "~1.0" should actually match 1.2, and anything before 2.0, unless there are other things constraining that package version.)

#2769841: Prefer caret over tilde in composer.json has some suggestions about what tends to be most appropriate for Drupal projects.

Lowell’s picture

Lowell CreditAttribution: Lowell as a volunteer commented

That's odd, but thanks. I will test some more.

I was basing this on actual testing. I will test again.

Lowell’s picture

Lowell CreditAttribution: Lowell as a volunteer commented

Ah, shit. I think I am starting to get it.

The ^ fixes the major version number, whereas the ~ fixes the "second from last" number. And because we are only using one "dot" in our requires, they act the same as each other.

^1.2 = 1.2 up to < 2.0
~1.2 = 1.2 up to < 2.0

^1.2.3 = 1.2.3 up to < 2.0
~1.2.3 = 1.2.3 up to < 1.3.0

also, because of "minimum-stability": "dev"
^1.0 and ~1.0 = 1.x-dev, 1.x-alpha, 1.x-beta, 1.x-rc, 1.0, up to < 2.0

gippy’s picture

gippy CreditAttribution: gippy commented

So, here I am at Drupalcon ... unable to participate in any workshops and unable to participate in any code sprints because I can no longer install any modules via Composer because one module has a broken .json file in Git? Is that really where we are? Look, I don't mean to be critical, but this is more than critical.

rodrigoaguilera’s picture

rodrigoaguilera
Primary language Spanish
Location Madrid
CreditAttribution: rodrigoaguilera as a volunteer commented

I opened an issue to stop using minimum-stability: dev in the popular drupal composer template
https://github.com/drupal-composer/drupal-project/issues/266
So the HEAD of a repo can't break the whole composer workflow.

zenphp’s picture

zenphp CreditAttribution: zenphp commented

I removed the minimum-stability: dev from the composer.json, and used stability flags on the projects that needed them.

Lowell’s picture

Lowell CreditAttribution: Lowell as a volunteer commented

Wow, thanks for that tip.

I kept the "minimum-stability": "dev" (for now) and added this to the "require" and now it works!
"drupal/superfish": "^1.0@RC"

Apparently the @RC prevents composer from looking at the dev branch,
and, presumably, it will allow superfish to update to more stable versions when they are available.

Win win!

Now it can work by removing (or changing) the "minimum-stability" and using the flags as needed, like "@DEV" or "@RC", etc, .

mroycroft’s picture

mroycroft CreditAttribution: mroycroft at Workday, Inc. commented

Looks like this issue can be closed now. Here's the commit with the fix: http://cgit.drupalcode.org/superfish/commit/?id=65db3cc and the resolving issue: #2839024: Require library sanely

mroycroft’s picture

mroycroft CreditAttribution: mroycroft at Workday, Inc. commented
Status: Active » Closed (duplicate)