Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.In parallel with the discussions surrounding how to integrate a composer based workflow into drupal and its modules, there are infrastructure requirements and impacts that should be considered/discussed/resolved in order to support a composer based workflow for the drupal ecosystem.
Some questions that need to be discussed/clarified in using packagist as our dependency metadata resolution repository.
- What impact will hosting a project the size of drupal have on packagist infrastructure? Can they handle whatever load we're going to send, and is there a cost associated with that?
- What metrics will we be able to collect from packagist?
- What does drupal.org need to do to get first class citizenship like github and bitbucket have for our git repos?
- How are security issues handled with packagist? Will the security team be able to unpublish insecure modules?
- Who owns/manages 'vendor' account at packagist?
- Would this have an impact on updates and the drupal.org's update system? i.e. what happens when a module checks in a composer.lock file with insecure versions?
- How are distributions/install profiles affected by something like this?
- Is packaging/tarballs still needed for d8+ if we go to composer based workflow?
| Order | Issue | Assignment | Comments |
|---|---|---|---|
| 1 | #1503234: Process Composer components when building Drupal core | who? | Composer for tarball |
| 2 | #2622462: Make sure packaging plays nice with GitHub api limits | who? | Api limits |
| 3 | #2622474: Testbots need some kind of composer cache | who? | Composer for testing |
| 4 | #2622394: Use composer for dependency resolution when running tests | who? | Composer for testing |
| 5 | #2622494: The updates process should alert about new versions in composer dependencies | who? | Depedency alerting |
| 6 | #2622482: Update download stats processing for Composer | who? | Stats |
| 7 | #2622466: Packaging should create a composer.lock file for distributions | who? | R&D - can we support distros this way? |
| 8 | [#] R&D How to support multi-sites? | who? | R&D |
| 9 | #2352091: Create (and maintain) a subtree split of Drupal core | who? | Eventually, subtree split core components |
| 10 | #2622470: Explore Toran Proxy for release packages | who? | R&D |
Comments
Comment #1
MixologicIn order to keep packagist up to date, we'll need something that connects our git infra to packagist.
Comment #2
MixologicWe may host drupalesque php libraries ourselves.
Comment #3
MixologicWe may want to allow use of "drupal core" - the codebase, independently of drupal, the product (with the front controllers, htaccess, and other structure). To do this we'll need to offer a subtree split of drupal, much like other projects offer.
Comment #4
hestenetComment #5
hestenetComment #6
drummComment #7
hestenetCore issue #3075954: Remove duplicate scaffold files is postponed on this issue.
Comment #8
hestenetComment #9
MixologicThis meta is sorely out of date, and not sure what purpose it serves. Im going to close it in favor of either new metas, or separate issues.
Comment #10
gregglesWhich is kind of great news!
Thanks to everyone for a lot of great work that has really helped in this area. Increasing our use of Composer has been a great improvement to productivity and repeatability for me and my coworkers. It's very appreciated.