This issue has a limited scope related to the file system layout of Drupal and how that interacts with Composer behaviors.
The reason for this limitation is so that it is a thing that can be understood, evaluated, and accomplished.
We currently have some contradictory ideas about how to use Drupal with Composer.
Here we see people wanting to use Composer to manage their Drupal site: #2477789: Use composer to build sites → (to the point that they want to stop offering a tarball: 🌱 Stop offering .tar.gz downloads Closed: outdated )
Here we see people wanting to not ever think about Composer at all during their site build: #2845379: Provide optional composer integration but don't force users to understand how to use composer →
Let's figure out how to combine these two motivations and give everyone what they want.
Currently, Drupal core has a composer.json file in its root.
This composer.json file defines a package called drupal/drupal. In the git repo, there is also a composer.lock file, which specifies the versions of other packages which are known-good.
In the context of Drupal core development, the drupal/drupal package is used to build the codebase for Composer requirements so that development can occur.
In the context of building the Drupal 8 distribution 'tarball', the drupal/drupal package and the composer.lock file are used to build the files necessary for the tar and zip file downloads.
Also of note is the existence of drupal-project. This project uses a lot of special-case code to move Drupal's files around towards the end of, for instance, having a server docroot with no vendor/ directory in it. These are all reasonable goals for Drupal, and are in fact documented on drupal.org → .
So, the desired goals are twofold:
1) Use Composer to build best-practices-type sites with isolated docroot and so forth. This has all the advantages you can learn about from talking to the drupal-project maintainers.
2) Leave Drupal like it is so that it can be used on cheap shared hosting by 'non-experts' who can't reconfigure a web server doc root (either due to lack of skill or because their hosting forces them, or whatever else). This has the advantage of leaving Drupal as an entry-level site building tool for people who want to host their own site but maybe aren't technical experts.
We have an existing solution for goal 1: drupal-project and other bespoke solutions. The problem with these out-of-core solutions is that they are inconsistent and confusing to someone who is new. Why would they choose drupal-project or whatever? They don't know. And the reason they don't know is because they are the target audience for goal 2.
If we were to make it so that drupal-project were not necessary, this would make many expert users happy. They could composer require all day long and be content. There would be no need for drupal-project maintainers to chase down special cases added to core, and accordingly, no need for site builders to wonder what process errors will be introduced in the next minor update.
And if we made it so that drupal-project were not necessary, then we would also make it easier to deal with distributions. Distributions would truly become a Composer-based build.
And guess what? One of our distributions could be the d.o tarball as we know it now. Let's name it drupal-tarball-project.
From @webchick #30:
"When I install any contributed module, I should be able to take exactly the same steps. Whether the maintainer chose to manage their dependencies in .info files or Composer is an implementation detail based on their own personal preferences, and should be utterly irrelevant to me as a site builder."
The most common ways of installing contrib modules are (I believe, in this order):
- Downloading the tarball and sticking it in /modules.
- drush dl/en modulename
- Using the Update Manager UI
We have a few general solution ideas:
Closed: outdated
Idea
Not all content is available!
It's likely this issue predates Contrib.social: some issue and comment data are missing.
Since this issue was updated composer 2 was released and package_manager is in core 🌱 Drupal 10 Core Roadmap for Automatic Updates Active . We have various issues still open for implementation, including some very big ones, but overall the ideas discussed here made their way into Drupal core and Drupal CMS already, we mostly need to finish the work now. Closing as outdated but crediting all the participants here.