Switch to packages.drupal.org from packagist.drupal-composer.org

Should this be part of the 1.00 release? Also note that the version tags for referencing modules changes between the old packagist site and the newer drupal.org site, so the entire composer.json will need to be changed.

I'd like to get this in before release, but we had some problems in early testing regarding dependencies when Lightning is is a dependency (e.g. Lightning Project). Most notably that dependencies of dependencies don't seem to get recognized. (We're working on getting those repeatable, documented, and resolved)

This issue will be in one of our sprints soon. Well before webflo's packagist is taken down.

I suggest this as a Lightning 8.x-1.01 target.

Well, we missed 1.01, but this is now ready for review in the 8.x-drupal-packagist branch.

This all seems to work great. And the D.O Packagist seems to be finding everything and working as expected. The problem is, D.O's packagist is ignoring Lightning's dependencies when Lightning is a dependency of a project (e.g. Lightning Project).

To fully test everything, I committed the NR branch referenced above to D.O as 8.x-2.x. Then I updated Lightning Project's "drupal-packagist" branch to point to the 8.x-2.x branch of Lightning on D.O. As a result, I got an empty modules/contrib directory. I was also missing stuff from the vendor directory that modules listed as dependencies.

To be clear, Lightning itself seems to build correctly when its dependencies come from D.O packagist... and Lightning Project will even build Lightning's dependencies correctly if I pull in Lightning itself from github - even when the version of Lightning pulled from github builds its own dependencies from D.O packagist.

It's only when a root project (like lightning project) references Lightning from the D.O packagist that the problem arises.

So, for now, this is postponed on something outside of our control. I'll work with D.O infra to try to figure out exactly what that is.

This issue with drush is also a blocker:
https://github.com/drush-ops/drush/issues/2261

...or we could drop support for the tarball :)

This is still blocked on #2763017: Dependencies of dependencies aren't installed when both dependencies are pulled from packages.drupal.org and #2715441: Support for distributions. Basically, the D.O packager does not process dependencies of distributions:

We currently do *not* process dependencies of distribution - hence why they are not yet "supported".

One of the problems with Lightning continuing to use packagist.drupal-composer.org (in addition to the fact that it is deprecated and not officially supported by the DA) is that other modules are starting to define their dependencies' versions assuming that the root composer file points to the D.O packager. Take Drupal Commerce's composer.json for example:

{
    "name": "drupal/commerce",
    "type": "drupal-module",
    "description": "Drupal Commerce is a flexible eCommerce solution.",
    "homepage": "http://drupal.org/project/commerce",
    "license": "GPL-2.0+",
    "require": {
        "drupal/core": "~8.2",
        "drupal/address": "~1.0",
        "drupal/entity": "1.x-dev",
        "drupal/entity_reference_revisions": "~1.0",
        "drupal/inline_entity_form": "~1.0",
        "drupal/profile": "1.x-dev",
        "drupal/state_machine": "~1.0",
        "commerceguys/intl": "~0.7"
    },
    "minimum-stability": "dev"
}

"drupal/address" defines it's version as "~1.0", but if you have packagist.drupal-composer.org defined as a packagist in your root composer.json file, it won't be able to find that version because it follows a different schema. (The equivalent on packagist.drupal-composer.org would be "drupal/address": "~8.1".)

Proposed workaround

While @mixologic has been very helpful in explaining the current restrictions, we haven't seen any movement towards resolving the current problems. As a result, I propose we work around the problem by submitting the Lightning distro to the standard packagist. Lightning will define it's dependencies according to the the D.O schema and the root scaffold project would define the https://packages.drupal.org/8 (D.O) repository for drupal packages.

See this slide deck for more details: https://docs.google.com/presentation/d/1kwUScdWW0nfae2QFVZ94pUPMRVeKgI-N...

Other considerations

Users will need to convert their dependency version constraints

This means that all current users of Lightning will need to redefine their drupal dependency version constraints to use the new schema. In order to facilitate this transition, I propose we make the switch in a new 8.x-2.x branch of Lightning. We could support security updates on the 1.x branch for 3(?) months to give users time to transition.

Drush make-convert

We currently use the drush make-convert command to generate our make files from our composer.lock file. The make files are in turn used by D.O to generate the tarball. I'm not sure if changing the version constraints schema will have any effect on this. Relevant issue: https://github.com/drush-ops/drush/issues/2261

Timeline

I'm not sure when the best time to make this switch is. packagist.drupal-composer.org's deprecation notice indicates it might be taken offline in January, but I don't think that will happen. Either way, I feel like we should get started on this sooner than later. Preferably before the new year.

This has been committed. The upgrade path lives in the 1.x branch and the actual change in the 2.x branch.

See this blog post for more information: http://lightning.acquia.com/blog/packagist-switch