Drush Make is being eventually going to be deprecated in favour of Composer. So, we should look at supporting Composer as an alternative to Drush Make for building platforms.

This article describes a workflow using drupal-composer/drupal-project. Part of the challenge here is that Drupal ends up installed in web/, but as far as I can tell, meta-data that would allow us to discover this isn't readily supplied, and appears hard-coded. Perhaps we could parse "installer-paths" or something, to figure this out.

Presumably, Composer-based installs could do things differently, and so we'd need a reasonably flexible solution to work with variations. In addition, drupal-composer/drupal-project appears to assume that the site will be installed into sites/default/, and hardcodes that as well, leaving /sites/default/settings.php world-writeable (i.e., mode 0600).

We should start looking into this, and perhaps suggest some changes to drupal-composer/drupal-project and similar projects to make them more flexible and secure.

Members fund testing for the Drupal project. Drupal Association Learn more

Comments

ergonlogic created an issue. See original summary.

ergonlogic’s picture

Priority: Normal » Major
Issue tags: +composer

bumping priority and tagging.

colan’s picture

We should probably use the official upstream source at Using Composer to install Drupal packages through Drupal.org.

spoetnik’s picture

Modern Distributions, like Open Social are already using Composer to install packages, and don't use a Make file anymore.

I am not that technical, but I would love to help testing Composer builds in Aegir.

muschpusch’s picture

There two problems right now:

a.) Installing a drupal composer based distribution by using the aegir frontend isn't possible right now.
b.) It's not possible to install a site which is using a drupal composer based code base at all. Which means there is no manual workaround for a.)

I would call b.) a critical issue when supporting D8 even though the discussion is huge. Composer is the standard in the php community, vanilla drupal is not using composer the way it should be used, drupal composer is. #1475510: Remove external dependencies from the core repo and let Composer manage the dependencies instead There is a lot progress in the composer integration issues and i must admit that i stopped following it since everything seems to work fine.

@ergonlogic that drupal composer assumes the installed site in sites/default doesn't need mean that it doesn't support a multi site setup. At least i couldn't find a reason why that wouldn't possible. IMHO. The actual sites/SOMESITE or DEFAULT shouldn't be part of the version control system and shouldn't be deployed when installing the platform anyways.

Isn't the main problem here: #2770077: RFC: Refactor how Aegir installs Drupal. which is already worked on?

helmo’s picture

One work around that should always be possible is to let composer create the platform tree by calling it manually, and then add that dir as a platform to Aegir, or re-verify if already added as platform.

spoetnik’s picture

a.) That's what this issue is about. Add de possibility to build a platform based on Composer, not on a Make-file or GIT
b.) I did some test with the social distribution, and I can install sites based on a composer based platform. This is my workflow.
1) Download Core
2) Download the profile in de /profiles/directory (profiles/social)
3) drush dl composer_manager
4) php modules/composer_manager/scripts/init.php
5) composer drupal-update
6) composer dump-autoload

This platform verifies, and I can install sites from this platform. As far as I understood 'composer_manager' is deprecated.

If I can be of any help regarding this issue, let me know.

helmo’s picture

I saw that the social distro also offers to install via a composer template in https://github.com/goalgorilla/social_template

This does download all the stuff in a 'html' sub-directory of the one you specify.

8thom’s picture

A possible option to support composer builds is to implement a build artifact repository.

You'd need a way to build out the source repo with a task runner like Jenkins or possibly a cloud CI platform like travis or circle, but at least the source repo could only contain your custom code + a composer.json referencing all dependences.

Docman is a project I was introduced to @ Drupalcon Dublin which might help with building this artifact repository -- https://github.com/Adyax/docman

mengi’s picture

This would be fantastic as Drupal Commerce 8-2.x now requires Composer.

This blog states that Composer Manager is deprecated and should not be used.

ergonlogic’s picture

We're converging on a solution to #2838489: Support drupal being in a subdirectory of a git repo. The attached patch then allows a git repo, built from a template like the one mentioned in #8, to run composer install, to build the dependencies for the platform.

While this patch add Composer support to hosting_git, it's actually pretty self-contained. The use of composer create-project is certainly interesting though, and shouldn't be much different in implementation to this patch. They could perhaps be bundled into a hosting_composer contrib module.

gusaus’s picture

FWIW there's some recent documentation on how to install Open Social that may be relevant to this issue.
https://www.getopensocial.com/blog/installing-open-social-with-composer

How to install Open Social with Composer locally

Before you can start with your installation you need to decide how you'd like to host your site. You can use the following templates to bootstrap your Open Social site:

* Platform.sh
* Pantheon
* Any webserver: just fork this template and change accordingly