Custom composer installer for Drupal projects

We encourage users to post events happening in the community to the community events group on https://www.drupal.org.
derhasi's picture

I'd like to share some thoughts on composer installers that we can use for supporting setting up a Drupal project with composer. I'd like to know about your assumptions and how we may be able to build common installer, that we can use maybe as a standard in the future.

David Barrat already did great work on a custom-installer. I was working on some code for that to preserve subpaths, so nested packages can be installed and updated, with hopefully no hiccups (Example composer.json for D7).
The flexible approach of David's installer is great, especially when we want or have to deal with other types of packages (as libararies, deployment scripts and so on). It would be great if we could add the composer/installer-notation to support paths for package types, but specific packages too, with wildcard support for both approaches.

I'm currently thinking about a approach for documenting patches. kasperg already pointed to https://github.com/netresearch/composer-patches-plugin, that might provide a solution for distributed patches. From my point of view, that will not fit my use case as adding patch files in the root composer.json seems not to be possible with that, but I may be wrong. But maybe that is something we could add to a drupal installer.

For a Drupal installer I also would expect a default behaviour with default paths for modules and themes (like sites/all/modules/contrib or modules/contrib), depending on the Drupal core. Additionally providing a "drupal-root" like ., htdocs, docroot,

I'm curios about your thoughts and experiences. So please comment and update the summary below. It would be great if we can provide a great installer (on https://github.com/drupal-composer?) anytime soon ;)

Summary

Challenges / Tasks

  • Provide default paths for drupal modules, themes, sites, profiles (depending on core version=
  • Make paths overridable per type and package
  • Dealing with nested packages and core
  • Set drupal root
  • Support patching projects
  • Support 3rd-party packages

Projects

Comments

Nice writeup. Well done

kasperg's picture

Nice writeup.

Well done regarding custom-installer. I appreciate going through composer/installers first. In my opinion a part of using composer is to reuse and contributing to existing projects where possible instead of writing our own.

Could you elaborate what the problems you see with netresearch/composer-patches-plugin are? This example shows how patches can be added to the root composer.json. Developer experience could be improved though.

Regarding installers I needed to wrap my head around the different concepts here: Composer installers and custom command line apps for installing frameworks as provided by Symfony and Laravel.

Regarding Composer installers I would prefer that we try to separate our needs (patching, custom install paths etc.) into separate installers instead of wrapping then all into one monolithic drupal-installer. To improve developer experience I suggest that we create a template package which can be used with the composer create-project command. Here we can pull in installers and setuop default configuration (paths, etc). This is also the approach taken by other projects such as Typo3, Silverstripe, October.

I think Implementing a separate installer is a nice goal but not something we need to solve right now.

Thank you

generalredneck's picture

Quick shoutout, Thanks for the example patch code. I was trying to figure it out and was having a hard time from just the examples on Composer Patches Plugin README.

Separating the needs is a

derhasi's picture

Separating the needs is a good approach. It could get tough in bringing multiple components to work together, but for now, you are right, we should try to separate the needs.

Preserve paths

I started with converting the preserve subpath feature from my installer fork to a separate composer plugin "derhasi/composer-preserver-paths" to be used in addition to any or no installer: see my updated composer.json for an implementation example.

Drupal installer

Nonetheless I still think we should provide a composer Drupal installer, that then would be build on top of the separate components and will provide an easy way of configuring the drupal installation with best practices. Instead of adding custom-installer and preserve-paths you could simply add "drupal-root": "htdocs" and the drupal installer would take care of anything else.

In terms of using custom-installer vs. Composer's Installers, I see quite an advantage in custom-installer as this will allow to configure custom package types. But Composer Installers has the option to provide paths per package name and per package type. Merging both approaches together in a "drupal-composer/custom-installer" could be something to think about.

Patches

IMHO, the biggest problem with netresearch/composer-patches-plugin is indeed the Developer Experience. It should be made much more simple without the need of distributed packages. I think it's important to make it easy to use, especially as applying patches could get quite vibrant within an actual project.

Within composer.json it could look something like this:

"extra": {
    "patches": {
      "drupal/views": [
        {
          "issue": "https://www.drupal.org/node/2272387",
          "description": "Getting rid of jump menu warning message",
          "url": "https://www.drupal.org/files/issues/views_jump_warning-2272387-10.patch",
          "version": "7.3.*"
        },
        {
          ...
        }
      ],
      "drupal/ctools": [
        ...
      ]
    }
  }

Making that format work, should be possible with a pure composer plugin (no installer), maybe even with building on top of the netresearch approach. I try to have a look into that.

create-project command

That's a good idea. But I do not think this is something that would replace a "Drupal installer", as you would need to configure some parts of your application in the Drupal way. create-project could be used more something like a Distribution or Install Profile.

Installers vs. Command line tools

I would separate the scope of those like that:

  • Composer plugins and installers: deal with source code managed: composer update replaces drush upc
  • Command line tools: deal with the whole application (database, vhost) and infrastructure: like drush

Command line tools could provide wrappers around composer functionality. For example "drush dl" could use "composer require" in the long term. In addition it could provide sensible defaults for the infrastructure, like using "packagist.drupal.org".

I think anything that can be achieved by composer plugins in a non-hacky way, should be solved with composer in the first place.

I agree with most points here

kasperg's picture

I agree with most points here derhasi.

Well done regarding derhasi/composer-preserver-paths! I look forward to taking that for a spin.

What parts of the application do you see the "Drupal installer" handle that is not handled by either composer.json or Drupals own install.php/drush si?

Patches

MiSc's picture

I think it is really impotant to get the patches thing sorted out, I could go for trying to do the suggested solution, but maybe I would like to rather move version up, like:

"extra": {
    "patches": {
      "drupal/views":{
        "version": "7.3.2": [
        {
          "issue": "https://www.drupal.org/node/2272387",
          "description": "Getting rid of jump menu warning message",
          "url": "https://www.drupal.org/files/issues/views_jump_warning-2272387-10.patch"
        }
      ]
     }
    }
  }

/* Mikke Schirén, https://digitalist/ */

@MiSc, why would you want to

derhasi's picture

@MiSc, why would you want to move the version?

IMHO, adding a version should not be mandatory, or at least it should be able to be loose version constraint, as you never know when a patch finally gets into the stable release.

btw: I added francoispluchino/composer-asset-plugin to the summary, as this quite a nice solution for pulling assets via bower.

I guess that removing the

MiSc's picture

I guess that removing the version totally is the most reasonable thing to do.

/* Mikke Schirén, https://digitalist/ */

Composer

Group organizers

Group notifications

This group offers an RSS feed. Or subscribe to these personalized, sitewide feeds: