1

I maintain skilling, a contrib module. This...

composer require drupal/skilling

... reports...

[RuntimeException] Could not load package drupal/skilling in https://packages.drupal.org/8: [UnexpectedValueException] Could not parse version constraint ~1.0@alpha2: Invalid version string "~1.0@alpha2"

[UnexpectedValueException] Could not parse version constraint ~1.0@alpha2: Invalid version string "~1.0@alpha2"

An older version of composer.json did use the string "~1.0@alpha2", but it was removed a while ago. Download the module's zip from D.O, and there is no such string in the file set once the zip file is expanded.

BTW, use the zip file, or Git the source files into contrib/modules, and Drupal installs everything just fine. It's just the composer install that's the problem.

I tried composer clearcache, but no dice. Using -vvv on 'composer require' didn't give me any info that I could interpret. Looking at composer's cache shows Strange Things. The file $skilling.json refers to the right release, but has '"drupal/token_custom":"~1.0@alpha2"' from long ago.

Help appreciated! The module can't be installed with Composer at the moment.

----- Update ARGH!! ----

@Clive is probably right, but I don't know how to fix it. Tried removing the line with the bad Composer version string in Git history with:

git filter-branch -f --tree-filter 'sed -i "/drupal\/token\_custom/d" composer.json' -- --all

Also tried BFG repo rewrite tool to replace the bad string.

Pushed. Created new releases. Cleared composer cache. composer require generates the same errors.

Afraid I don't understand Clive's suggestion to rebase a fix onto the branch containing the invalid version string. How is that done?

Improve this question
3
  • 1
    The file $skilling.json refers to the right release, but has '"drupal/token_custom":"~1.0@alpha2"' from long ago It contains all the releases so it makes sense that the string is there...I guess Composer parses all of them each time. I suspect one way to fix it would be to rebase a fix onto the branch containing the invalid version string (looks like that's 1.0.0), then release a new version of the module. At that time the provider file should hopefully be regenerated with the tagged composer.json versions as they exist at that time (i.e. with the fixed version string)
    – Clive ♦
    Commented Aug 16, 2019 at 20:05
  • @Clive is right: The error is caused from the fact the custom code running for the packages.drupal.org domain parses all the project branches, even the ones that could not be used from drupal.org to create a development snapshot.
    – avpaderno ♦
    Commented Aug 17, 2019 at 11:37
  • Tried various things, listed under ARGH in the editing question. How would I implement the rebasing suggestion?
    – Kieran Mathieson
    Commented Aug 19, 2019 at 16:35

1 Answer 1

Reset to default
1

Im the maintainer of packages.drupal.org - I went ahead and deleted the invalid data out of the database, and this will install now.

I've also opened and issue on drupal.org to put more defensive measures in place. https://www.drupal.org/project/project_composer/issues/3076342

I think something must have changed in how permissive composer is with certain bad version constraints.

Improve this answer
1

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.