Drupal.org Composer Service (façade)

We are probably not going to be running a version of packagist on the d.o. infrastructure, and would more likely lean towards the solution proposed by cweagans whereby we support all of composers features of searching and requiring by providing equivalent json endpoints. Its less risk and easier for us to do it that way.

I've rummaged around in the source of packagist to see what it *does* provide, and the vast majority of it is stuff that drupal.org itself is already providing, so it doesnt make sense to have duplicate services or datasets. We are *not* going to integrate drupal.org users into packagist, allow people to upload packages using the interface, or even *have* the web interface for package discovery. In short, most of what the packagist software does, drupal.org is already doing, with the sole exception of providing metadata about the packages in a format composer works with.

Basically we're aiming to make it so that if you are using composer from the command line, it just works. But we are *not* planning on duplicating package discovery, counts and stats - all of that already exists, and we're not going to be merging two systems together. If there are things that packagist offers that isnt on project pages *now* (like parsing the composer.json and putting up 'requires' data for example, we'll add that to the d.o. project pages.

Updating the issue summary to reflect that we'll be using this as a meta issue for

A) This is a bad idea.

B) ...

8.x-1.0 -> 8.1.0 (currently used on packagist.drupal-composer.org)
8.x-1.0 -> 801.0.0 (what we decided upon at Drupalcon)
8.x-1.0 -> 1.0.0 (only list Drupal 8 modules, rework before D9)

Ideally, composer.json files for modules should declare their dependency on core. So if your module package is drupal/frammistat:1.0.0 and it requires drupal/drupal:~8.0 then there is no problem.

But because we're thinking about automating all this and using version numbers as ridiculous as 801.0.0, we can't do that.

Which is part of why A) above is true.

The wrongness of it aside, here's a solution: *.info and *.info.yml files declare their core dependency. So therefore, a Drupal version like 8.x-1.0 which has an info file that says core: 8.x would resolve to module version 1.0.0 with a dependency on some version of D8, represented by 8.x in the info file. The problem is not in the 1.0 part but the core: 8.x part, because that's ambiguous.

Thus, once that problem is solved, your module's version is 1.0.0, because *that's what it really is.* And the dependency is on a specific version of Drupal, because *that's what it really is.* And if you have the wrong version of Drupal for 1.0.0, then composer will tell you because *that's what it's supposed to do.*

And if we end up with version numbers like 801.0.0 then I dunno what.

For those following this issue who may want to comment, child issue #2622450: Provide semver versioning shim for Drupal.org Composer facade has been updated with the translation format the semver shim will use.

Short version: separate end points for platform version, and then relatively straightforward conversion to semver without needing to include platform version in the format.

It might be useful to ping Seldaek to see if he has some insights for this issue, as he often has on other ones.

Seldaek attended our monthly meetings when we were building the Composer facade and provided a lot of valuable input.

This is done, right?

yeah, mostly. theres always more features, but we dont need a meta issue anymore now that theres a whole queue to track things.