I've spent some time today trying to wrap my head around Composer, and it seems like it would be really useful if there were a more Drupally target for installed composer libraries. I.e., for Drupal 6 and 7 could we do something to have Composer drop off libraries in sites/all/libraries?

According to this handy custom installers page, there is some basis to think it's possible, though it looks like it may be a per-package configuration.

Comments

robloach’s picture

robloach
he/him
commented

Sounds pretty neat! Definitely something to consider.

robloach’s picture

robloach
he/him
commented

Hmmm, Drupal Composer Installer....

mycustommodule/composer.json

{
    "type": "drupal-module",
    "require": {
        "drupal/composer-installer": "*",
        "me/myothermodule": "*"
    }
    "repositories": [
        {
            "type": "composer",
            "url": "http://packages.drupalbin.com"
        }
    ]
}

myothermodule/composer.json

{
    "type": "drupal-module",
    "require": {
        "drupal/composer-installer": "*"
    }
    "repositories": [
        {
            "type": "composer",
            "url": "http://packages.drupalbin.com"
        }
    ]
}

If you run "drush composer install" on mycustommodule, it will download myothermodule to sites/all/modules/myothermodule. Innnteresting.

bastnic’s picture

bastnic commented

@Rob Loach: just to say that you rock!

I was planning to develop exactly that Composer Installer so I'm very pleased that I did not have to. Thanks.

robloach’s picture

robloach
he/him
commented

It's probably very broken! Didn't really test it much...I do accept pull requests though! :-)

Grayside’s picture

Grayside commented

Awesome! Super excited that you jumped on this. I hope to find time to help out...

Here's a couple quick thoughts/requests that I'll try to follow up on...

  • sites/all is not always the preferred destination. Should default to the currently active site from context, all if non-specific/default.
  • Doesn't address my main query, about how to drop external libraries in a Drupal-friendly location.
patcon’s picture

patcon commented

This is SO awesome. I hope I have more time to look into custom installers...

Grayside’s picture

Grayside commented

Did a bit of exploration. Finding it tricky to wrap my head around this. I think my (limited) understanding of Composer is battling my understanding of drush make.

Spent some time looking at how to treat drupalcode.org as a package repository (maybe it's a modified Git driver?).

robloach’s picture

robloach
he/him
commented

Ah, interesting... GitHubDriver looks pretty neat.

Grayside’s picture

Grayside commented

And as long as we're brainstorming random ways to trick out Composer, the downloader architecture looks like we could shell out to drush. This would be nice, as the logic of good default code versions and where to save the file on disk could be left to the existing logic in drush pm-download.

patcon’s picture

patcon commented
Title: Custom Composer Installer? » [META] Composer-Drush integration ideas

Did I mention that I really really like this conversation? :)

Should we turn this into a meta-issue to discuss potential ways to use Composer, then talk about creating some coherent sub-issues to investigate and experiment and report back? Do you guys mind that approach?

I'm going to change it, but feel free to flip it back

As for another idea, was reading through the docs and came across the type called metapackage:

An empty package that contains requirements and will trigger their installation, but contains no files and will not write anything to the filesystem. As such, it does not require a dist or source key to be installable.

https://github.com/composer/composer/pull/258
https://help.ubuntu.com/community/MetaPackages

Sounds like it might be a good candidate to take the place of drush makefiles.
https://gist.github.com/2815829

So it seems like so far we've got a few ideas floating in here:

  • custom installer for dropping components in drupaly places [experimental code]
  • custom VCS driver to handle d.o package acquisition (git clone and tarball)
  • baby-step toward drush-composer integration by using downloaders from drush
  • metapackages as drush makefile
patcon’s picture

patcon commented

Also, have been confused by the apparent lack of recursive resolution, but seems it's actually just that "right now –- and probably always –- composer does not resolve repositories recursively, it only does for dependencies available in packagist.org."

Might be worth monitoring that, as it means Composer can't recurse through any projects we self-host. In the current scheme, packagist.org would need to be our central hub in order for composer to be a true successor to drush make...

patcon’s picture

patcon commented
Issue tags: +drush, +drush make, +Composer

tagging

Grayside’s picture

Grayside commented

@patcon the software running packagist.org is open source, and either that or a lightweight version is already up at http://packages.drupalbin.com/.

This implies that while recursive dependencies cannot currently be supported, we do have code available to see how they handle it, and contemplate the path toward the landslide shift of cooking composer into Drupal. After all, what are .info files?

I agree, this issue has spun off into meta-land. :)

Grayside’s picture

Grayside commented

By way of @cell, https://github.com/shama/baton.

robloach’s picture

robloach
he/him
commented

Would be great to port the Drupal Root detection over to http://github.com/composer/installers .

patcon’s picture

patcon commented

I think this would be undesirable for people interested in using composer.json files for their install profiles in the interim, right?