>>> [!note] Migrated issue <!-- Drupal.org comment --> <!-- Migrated from issue #2551607. --> Reported by: [cweagans](https://www.drupal.org/user/404732) Related to !171 >>> <p>With Drupal 8 now released, and based on some good discussions had so far in this thread and elsewhere, we have a plan to begin to move forward with composer support, particularly the Drupal.org components. There is certainly additional discussion and planning to be done - but it would be best to focus those conversations in the appropriate metas below. </p> <h2>Meta Issues for Composer Support</h2> <p><span class="drupalorg-gitlab-issue-link project-issue-status-info project-issue-status-7"><a href="https://www.drupal.org/project/drupalorg/issues/2576285" title="Status: Closed (fixed)">#2576285: Drupal.org Composer Service (fa&ccedil;ade)</a></span><br> <span class="drupalorg-gitlab-issue-link project-issue-status-info project-issue-status-7"><a href="https://www.drupal.org/project/infrastructure/issues/2485011" title="Status: Closed (fixed)">#2485011: Infrastructure Requirements to support Composer based workflows</a></span><br> <span class="drupalorg-gitlab-issue-link project-issue-status-info project-issue-status-6"><a href="https://www.drupal.org/project/drupalorg/issues/2622420" title="Status: Closed (works as designed)">#2622420: Site-builders should be able to use projects with composer dependencies</a></span><br> <span class="drupalorg-gitlab-issue-link project-issue-status-info project-issue-status-6"><a href="https://www.drupal.org/project/drupalorg/issues/2622400" title="Status: Closed (works as designed)">#2622400: Explore ways to make Composer support more robust</a></span> </p> <h3>Next steps</h3> <ul> <li>The initial roll out of the Drupal.org Composer Facade is complete, and Drupal.org composer repositories are now available for Drupal 7 and Drupal 8. Documentatoin is available here: <a href="https://www.drupal.org/node/2718229">https://www.drupal.org/node/2718229</a> </li> <li>Bug fixes to the alpha release</li> <li>Stable release</li> <li>Drupal Core should be updated to use D.O's composer endpoints</li> <li>Feature enhancements, as outlined in the plan issues above</li> </ul> <h2>History</h2> <p>We've been going back and forth in various issues about what the path forward should be for "official" Composer support for Drupal extensions. Hopefully, we can come to an agreement here before we go too much further down any one path.</p> <p>I've attempted to summarize the arguments here, though I recognize that I may be biased. If you have any other arguments for any of the solutions (or other solutions that we haven't considered), please add to the table</p> <h2>Must haves:</h2> <ul> <li>Expose Drupal extensions to Composer</li> <li>Survive the load that the Drupal community will put on it</li> <li>Be updated as quickly as possible</li> <li>Easy to use (especially for those new to Drupal) </li><li> </li></ul> <h2>Nice to haves:</h2> <ul> <li>Be updated instantly</li> <li>Avoid extra repo lines in composer.json if possible</li> <li>Ideally allow us to notify site owners/developers when they're doing something that has weird licensing implications if we can't outright prevent it</li> <li>Support the wider PHP community (rather than just Drupal) </li></ul> <h2>Summary of options</h2> <table> <thead> <tr> <th>Solution</th> <th>Pros</th> <th>Cons</th> </tr> </thead> <tbody> <tr> <td><strong>Pushing data directly to packagist</strong></td> <td> <ul> <li>The standard and official source for composer packages</li> <li>Packagist is where all the other packages are that Drupal already uses (drupal/core, symfony, phpunit etc)</li> <li>Packagist devs seem to be willing to accept new features from us</li> <li>Does not require any additional repo lines in composer.json - packagist.org is the default</li> <li>Embraces the PHP ecosystem</li> <li>Any effort / time / money / support benefits the whole PHP community</li> <li>Increases package count</li> <li>Familiar to PHP community</li> <li>Supported by Packagist / composer maintainer</li> <li>Gives Packagist more visability</li> <li>API on packagist already contributed to by Drupal community for this requirement</li> <li>d.o will soon depend on packagist for packaging core</li> <li>d.o already has a testbot that depends on packagist</li> </ul> </td> <td> <ul> <li>"Fast and reliable" isn't really promised by Packagist (but this is something we can help with)</li> <li>Adds yet another place that modules are undiscoverable (we would still use Drupal.org for discovering modules)</li> <li>Increases package count, releases, and traffic for Packagist in a pretty significant way - causes a problem for other people (forces packagist to have a more robust infrastructure, with Drupal's support)</li> <li>Pushes many projects (modules, themes, profiles, drush extensions) that aren't at all applicable to the wider PHP community (as so many existing projects)</li> <li>Composer docs say that it may be a good idea not to do this (although they are very must open to it)</li> <li>Requires us to build a queueing mechanism in the event we try to push data to Packagist and the request fails/packagist is down</li> <li>Requires us to fix semantic versioning in contrib modules to something that will work (which should be done anyway)</li> <li>Requires us to encourage module developers to add composer.json to their repos. Module would not be usable by composer without it. (which they should already be familiar with from any other PHP project)</li> </ul> </td> </tr> <tr> <td colspan="3"> <hr></td> </tr> <tr> <td><strong>packagist.drupal-composer.org</strong></td> <td> <ul> <li>Already works</li> <li>Drupal community supported</li> <li>Does not require contrib maintainers to add a composer.json to their project</li> </ul> </td> <td> <ul> <li>Relies on scraping data from Drupal.org</li> <li>Unique to Drupal (drupalism)</li> <li>May not be trusted by enterprise users</li> <li>Requires adding a repo to your sites root composer.json for packagist.drupal-composer.org</li> <li>Needs supporting</li> </ul> </td> </tr> <tr> <td colspan="3"> <hr></td> </tr> <tr> <td><strong>Serving repo JSON data directly from Drupal.org</strong></td> <td> <ul> <li>Very straightforward engineering effort</li> <li>Doesn't require parsing through all the repos (most data is already in db - except composer.json files in the repos themselves)</li> <li>May not require contrib maintainers to add a composer.json to their project unless they actually have dependencies.</li> <li>Updates instantly</li> <li>Leverages the existing infrastructure for Drupal.org (reliable, fast, geographically distributed)</li> <li>Doesn't wholly rely on a third party service (mitigates outage risks)</li> <li>Allows us to continue to track download stats and site analytics</li> <li>Allows us to resolve the subproject problem without having to delete all the drupal projects from packagist and re-create them - we can just change the JSON we're serving</li> <li>Allows us to 'fix' semantic versioning for composer without having to fix every piece of code on drupal.org that makes assumptions about the versioning scheme</li> <li>Could implement licensing checks of dependencies in drupal modules(?)</li> </ul> </td> <td> <ul> <li>Requires adding a repo to your sites root composer.json for packages.drupal.org</li> <li>May seem unfamiliar / unusual to non-drupal users / Not standard practice</li> <li>Needs supporting</li> <li>Any non-drupal dependencies would still require metadata from packagist.org </li><li> </li><li>Unique to Drupal (drupalism)</li> <li>Non-standard implementation (to output standard json)</li> </ul> </td> </tr> <tr> <td colspan="3"> <hr></td> </tr> <tr> <td><strong>Pushing data to a self hosted Packagist/Satis instance</strong></td> <td> <ul> <li>Familiar interface</li> <li>More control</li> <li>Leverages the existing infrastructure for Drupal.org (reliable, fast, geographically distributed)</li> <li>Doesn't rely on a third party service (mitigates outage risks)</li> <li>Allows us to continue to track download stats and site analytics</li> </ul> </td> <td> <ul> <li>Relies on a fairly lengthy process to update data from d.o database</li> <li>Another application to maintain</li> <li>Requires adding a repo to your sites root composer.json for packages.drupal.org</li> <li>Unique to Drupal (drupalism)</li> </ul> </td> </tr> </tbody> </table> > Related issue: [Issue #2547617](https://www.drupal.org/node/2547617) > Related issue: [Issue #2547385](https://www.drupal.org/node/2547385) > Related issue: [Issue #2485011](https://www.drupal.org/node/2485011) > Related issue: [Issue #2002304](https://www.drupal.org/node/2002304) > Related issue: [Issue #1612910](https://www.drupal.org/node/1612910) > Related issue: [Issue #2576285](https://www.drupal.org/node/2576285) > Related issue: [Issue #2631056](https://www.drupal.org/node/2631056)