0

Background

I'm applying updates (including security updates) to a Drupal 8 site.

Problem

When I run composer update, I'm getting the following error multiple times: The requested xxxxx package exists as yyyyy but these are rejected by your constraint. :

    Loading composer repositories with package information
    Updating dependencies (including require-dev)
    Your requirements could not be resolved to an installable set of packages.

          Problem 1
            - The requested package drupal/devel 8.* exists as drupal/devel[dev-

1.x, 1.x-dev, 1.0.0-rc1, 1.0.0-beta1, 1.0.0-alpha1] but these are rejected by your constraint.
      Problem 2
        - The requested package drupal/migrate_tools 8.* exists as drupal/migrate_tools[dev-3.x, 3.x-dev, dev-2.x, 2.x-dev, dev-1.x, 1.x-dev, 3.0.0-beta1, 2.0.0, 2.0.0-rc1, 2.0.0-beta1, 1.0.0, 1.0.0-beta1] but these are rejected by your constraint.
      Problem 3
        - The requested package drupal/migrate_upgrade 8.* exists as drupal/migrate_upgrade[dev-3.x, 3.x-dev, dev-2.x, 2.x-dev, dev-1.x, 1.x-dev, 3.0.0-rc1, 3.0.0-beta1, 2.0.0, 2.0.0-rc1, 2.0.0-beta1, 1.0.0] but these are rejected by your constraint.
      Problem 4
        - The requested package drupal/admin_toolbar 8.* exists as drupal/admin_toolbar[dev-1.x, 1.x-dev, 1.19.0, 1.18.0, 1.17.0, 1.16.0, 1.15.0, 1.14.0, 1.13.0, 1.12.0, 1.11.0, 1.10.0, 1.9.0, 1.8.0, 1.7.0, 1.6.0, 1.5.0, 1.4.0, 1.3.0, 1.2.0, 1.1.0, 1.0.0] but these are rejected by your constraint.
      Problem 5
        - The requested package drupal/libraries 8.* exists as drupal/libraries[dev-3.x, 3.x-dev] but these are rejected by your constraint.
      Problem 6
        - The requested package drupal/pathauto 8.* exists as drupal/pathauto[dev-1.x, 1.x-dev, 1.0.0-rc1, 1.0.0-beta2, 1.0.0-beta1, 1.0.0-alpha3, 1.0.0-alpha2, 1.0.0-alpha1] but these are rejected by your constraint.
      Problem 7
        - The requested package drupal/honeypot 8.* exists as drupal/honeypot[dev-1.x, 1.x-dev, 1.24.0, 1.23.0, 1.22.0, 1.21.0, 1.19.0-beta14, 1.19.0-beta13, 1.18.0-beta6, 1.18.0-beta5, 1.18.0-beta4, 1.18.0-beta3, 1.18.0-beta2, 1.18.0-beta1, 1.18.0-alpha15, 1.16.0-beta11, 1.16.0-beta10, 1.16.0-beta6, 1.14.0-beta5, 1.14.0-beta4, 1.14.0-beta3, 1.14.0-beta2, 1.14.0-beta1] but these are rejected by your constraint.
      Problem 8
        - The requested package drupal/metatag 8.* exists as drupal/metatag[dev-1.x, 1.x-dev, 1.0.0, 1.0.0-beta12, 1.0.0-beta11, 1.0.0-beta10, 1.0.0-beta9, 1.0.0-beta8, 1.0.0-beta7, 1.0.0-beta6, 1.0.0-beta5, 1.0.0-beta4, 1.0.0-beta3, 1.0.0-beta2, 1.0.0-beta1] but these are rejected by your constraint.
      Problem 9
        - The requested package drupal/mollom 8.* exists as drupal/mollom[dev-1.x, 1.x-dev, 1.2.0, 1.1.0, 1.0.0, 1.0.0-rc2, 1.0.0-rc1, 1.0.0-beta1, 1.0.0-alpha5, 1.0.0-alpha4, 1.0.0-alpha3, 1.0.0-alpha2, 1.0.0-alpha1] but these are rejected by your constraint.
      Problem 10
        - The requested package drupal/smtp 8.* exists as drupal/smtp[dev-1.x, 1.x-dev, 1.0.0-beta2, 1.0.0-beta1, 1.0.0-alpha2, 1.0.0-alpha1, 1.0.0-alpha0] but these are rejected by your constraint.
      Problem 11
        - The requested package drupal/token 8.* exists as drupal/token[dev-1.x, 1.x-dev, 1.0.0-rc1, 1.0.0-beta2, 1.0.0-beta1, 1.0.0-alpha2, 1.0.0-alpha1] but these are rejected by your constraint.
      Problem 12
        - The requested package drupal/simple_sitemap 8.* exists as drupal/simple_sitemap[dev-2.x, 2.x-dev, dev-1.x, 1.x-dev, 2.9.0, 2.8.0, 2.7.0, 2.6.0, 2.5.0, 2.4.0, 2.3.0, 2.2.0, 2.1.0, 1.11.0, 1.10.0, 1.9.0, 1.8.0, 1.7.0, 1.6.0, 1.5.0, 1.4.0, 1.3.0, 1.2.0, 1.1.0, 1.0.0] but these are rejected by your constraint.
      Problem 13
        - The requested package drupal/superfish 8.* exists as drupal/superfish[dev-1.x, 1.x-dev, 1.0.0-rc6, 1.0.0-rc5, 1.0.0-rc4, 1.0.0-rc3, 1.0.0-rc2, 1.0.0-rc1] but these are rejected by your constraint.
      Problem 14
        - The requested package drupal/google_analytics 8.* exists as drupal/google_analytics[dev-2.x, 2.x-dev, 2.1.0, 2.0.0, 2.0.0-rc1] but these are rejected by your constraint.
      Problem 15
        - The requested package drupal/video_embed_field 8.* exists as drupal/video_embed_field[dev-1.x, 1.x-dev, 1.4.0, 1.3.0, 1.2.0, 1.1.0, 1.0.0, 1.0.0-rc8, 1.0.0-rc7, 1.0.0-rc6, 1.0.0-rc5, 1.0.0-rc4, 1.0.0-rc3, 1.0.0-rc2, 1.0.0-rc1] but these are rejected by your constraint.
      Problem 16
        - The requested package drupal/masquerade 8.* exists as drupal/masquerade[dev-2.x, 2.x-dev, 2.0.0-beta1, 1.0.0-beta1] but these are rejected by your constraint.
      Problem 17
        - The requested package drupal/extlink 8.* exists as drupal/extlink[dev-1.x, 1.x-dev, 1.0.0, 1.0.0-alpha3, 1.0.0-alpha2, 1.0.0-alpha1] but these are rejected by your constraint.
      Problem 18
        - The requested package drupal/embed 8.* exists as drupal/embed[dev-1.x, 1.x-dev, 1.0.0, 1.0.0-rc3, 1.0.0-rc2, 1.0.0-rc1] but these are rejected by your constraint.
      Problem 19
        - The requested package drupal/entity_embed 8.* exists as drupal/entity_embed[dev-1.x, 1.x-dev, 1.0.0-beta2, 1.0.0-beta1, 1.0.0-alpha3, 1.0.0-alpha2, 1.0.0-alpha1] but these are rejected by your constraint.
      Problem 20
        - The requested package drupal/node_view_permissions 8.* exists as drupal/node_view_permissions[dev-1.x, 1.x-dev, 1.0.0] but these are rejected by your constraint.
      Problem 21
        - The requested package drupal/paragraphs ^8.1@RC exists as drupal/paragraphs[dev-1.x, 1.x-dev, 1.1.0, 1.0.0, 1.0.0-rc5, 1.0.0-rc4, 1.0.0-alpha2, 1.0.0-alpha1] but these are rejected by your constraint.
      Problem 22
        - The requested package drupal/simple_gmap 8.* exists as drupal/simple_gmap[dev-1.x, 1.x-dev, 1.2.0, 1.1.0, 1.0.0] but these are rejected by your constraint.
      Problem 23
        - The requested package drupal/entity_browser 8.* exists as drupal/entity_browser[dev-1.x, 1.x-dev, 1.0.0-rc2, 1.0.0-rc1, 1.0.0-beta4, 1.0.0-beta3, 1.0.0-beta2, 1.0.0-beta1, 1.0.0-alpha12, 1.0.0-alpha11, 1.0.0-alpha10, 1.0.0-alpha9, 1.0.0-alpha8, 1.0.0-alpha7, 1.0.0-alpha6, 1.0.0-alpha5, 1.0.0-alpha4, 1.0.0-alpha3, 1.0.0-alpha2, 1.0.0-alpha1] but these are rejected by your constraint.
      Problem 24
        - The requested package drupal/dropzonejs 8.1.x-dev exists as drupal/dropzonejs[dev-1.x, 1.x-dev, 1.0.0-alpha6, 1.0.0-alpha5, 1.0.0-alpha4, 1.0.0-alpha3, 1.0.0-alpha2, 1.0.0-alpha1] but these are rejected by your constraint.
      Problem 25
        - The requested package drupal/inline_entity_form 8.* exists as drupal/inline_entity_form[dev-1.x, 1.x-dev, 1.0.0-beta1, 1.0.0-alpha6, 1.0.0-alpha5, 1.0.0-alpha4, 1.0.0-alpha3, 1.0.0-alpha2, 1.0.0-alpha1] but these are rejected by your constraint.
      Problem 26
        - The requested package drupal/file_browser 8.1.x-dev exists as drupal/file_browser[dev-1.x, 1.x-dev, 1.0.0-alpha4, 1.0.0-alpha3, 1.0.0-alpha2, 1.0.0-alpha1] but these are rejected by your constraint.
      Problem 27
        - The requested package drupal/sitemap ^8.1 exists as drupal/sitemap[dev-2.x, 2.x-dev, dev-1.x, 1.x-dev, 1.3.0, 1.2.0, 1.1.0, 1.0.0, 1.0.0-rc2, 1.0.0-rc1, 1.0.0-beta3, 1.0.0-beta2, 1.0.0-beta1, 1.0.0-alpha1] but these are rejected by your constraint.
      Problem 28
        - The requested package drupal/redirect 8.1.0-alpha1 exists as drupal/redirect[dev-1.x, 1.x-dev, 1.0.0-alpha4, 1.0.0-alpha3, 1.0.0-alpha2, 1.0.0-alpha1] but these are rejected by your constraint.

Root cause

I think this might be related to the move to a new package manager address ("endpoint) which appears to be using a different versioning convention on the basis of the errors. Obviously I would want to follow the new versioning system if that is the new standard.

Here's how I have changed my composer.json accordingly to use the new package manager, here is the relevant snippet of my git diff showing what I changed from and to:

     "repositories": [
         {
             "type": "composer",
-            "url": "https://packagist.drupal-composer.org"
+            "url": "https://packages.drupal.org/8"^M
+        },^M
+        {^M
+            "type": "composer",^M
+            "url": "https://packagist.org"^M
         },

Question about possible solutions

The only solution I can think of at the moment is for me to attempt to guess the new version of each "package" (i.e. Drupal module), one by one and edit the composer.json file.

This might not be too bad to do if it is a one off, but I wondered if there is any definitive conversion utility to map between the old and new versioning. Even though perhaps it is a bit of pain to for a one of, it might be more cumbersome for those who are upgrading multiple sites which dozens of modules.

Can anyone advise on automation, please? Thank you for your help.

Just to I've also done the following in prep, before doing the composer update:

composer self-update
cleared composer cache (by removing the folder to force it to be rebuilt)

I've done some research but not found anything about automation.

Annotated Research:

1

Solution for me that got me past that error was to do a global find/replace all of "8.*" with "*" in my composer.json and also for specific versions rewrite them in the format convention for the new package manager, a bit of guesswork. Here's my full changes shown as a diff (i.e. the original with - prefix, followed by the new with the + prefix):

-               "drupal/devel": "8.*",
-        "drupal/migrate_tools": "8.*",
-               "drupal/migrate_upgrade": "8.*",
-               "drupal/admin_toolbar": "8.*",
-        "drupal/coder": "8.2.5",
-        "drupal/libraries": "8.*",
-        "drupal/pathauto": "8.*",
-               "drupal/honeypot": "8.*",
-               "drupal/metatag": "8.*",
-        "drupal/mollom": "8.*",
-               "drupal/smtp": "8.*",
-        "drupal/token": "8.*",
-               "drupal/simple_sitemap": "8.*",
-        "drupal/superfish": "8.*",
-        "drupal/google_analytics": "8.*",
-        "wkse/google_tag": "^8.0",
-        "drupal/video_embed_field": "8.*",
-        "drupal/masquerade": "8.*",
-        "drupal/extlink" : "8.*",
-        "drupal/embed" : "8.*",
-        "drupal/entity_embed" : "8.*",
-        "drupal/node_view_permissions": "8.*",
-        "drupal/paragraphs": "^8.1@RC",
-        "drupal/simple_gmap": "8.*",
-        "drupal/entity_browser": "8.*",
-        "drupal/dropzonejs": "8.1.x-dev",
-        "drupal/inline_entity_form": "8.*",
-        "drupal/file_browser": "8.1.x-dev",
-        "drupal/sitemap": "^8.1",
+               "drupal/devel": "*",^M
+        "drupal/migrate_tools": "*",^M
+               "drupal/migrate_upgrade": "*",^M
+               "drupal/admin_toolbar": "*",^M
+        "drupal/coder": "^2.5",^M
+        "drupal/libraries": "*",^M
+        "drupal/pathauto": "*",^M
+               "drupal/honeypot": "*",^M
+               "drupal/metatag": "*",^M
+        "drupal/mollom": "*",^M
+               "drupal/smtp": "*",^M
+        "drupal/token": "*",^M
+               "drupal/simple_sitemap": "*",^M
+        "drupal/superfish": "*",^M
+        "drupal/google_analytics": "*",^M
+        "wkse/google_tag": "*",^M
+        "drupal/video_embed_field": "*",^M
+        "drupal/masquerade": "*",^M
+        "drupal/extlink" : "*",^M
+        "drupal/embed" : "*",^M
+        "drupal/entity_embed" : "*",^M
+        "drupal/node_view_permissions": "*",^M
+        "drupal/paragraphs": "*",^M
+        "drupal/simple_gmap": "*",^M
+        "drupal/entity_browser": "*",^M
+        "drupal/dropzonejs": "*",^M
+        "drupal/inline_entity_form": "*",^M
+        "drupal/file_browser": "*",^M
+        "drupal/sitemap": "^1.3",^M
         "enyo/dropzone": "4.2.0",
         "desandro/masonry": "3.3.1",
         "desandro/imagesloaded": "3.1.8",
         "mehrpadin/superfish": "2.0",
-        "drupal/redirect": "8.1.0-alpha1"
+        "drupal/redirect": "*",^M
+        "drupal/redis": "1.0-beta1"^M

Update

In the end as a final solution. I set each module to a specific version, based on the latest available stable or if not, then latest rc, beta or alpha from each module's project page on drupal.org But I had to change the versioning convention from drupal.org to what composer understands e.g. 8.x-1.0 on drupal.org will be 1.0.0 in composer. Thanks Berdir for your input.

This approach gives me control over what versions to use. I set each module to a specific version, based on the latest available stable or if not, then latest rc, beta or alpha from each module's project page on drupal.org But other people might necessarily need an earlier version of certain modules depending on what they are doing. The overall point is that specific version are used instead of the range notation that would allow composer to choose. It really depends on what one needs to do but I like the ability to choose specific versions and then choose to modify when newer versions come out.

  • I will probably accept my own answer, but your input welcome – therobyouknow Apr 9 '17 at 20:47
  • 2
    Yes, simply replacing 8. with nothing should do the trick in most cases. I'd recommend against using just * (just like you shouldn't use just 8.* before) however, as you will get major updates of those modules, which might break your site, not have an upgrade path or so. So do something like 1.* or ~1.0 instead and specify an explicit major version. – Berdir Apr 10 '17 at 16:10
  • +1 thanks Berdir. Ultimately I set each module to a specific version, based on the latest available stable or if not, then latest rc, beta or alpha from each module's project page on drupal.org But I had to change the versioning convention from drupal.org to what composer understands e.g. 8.x-1.0 on drupal.org will be 1.0.0 in composer. I'll update the answer with this comment too. – therobyouknow May 10 '17 at 13:11

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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