When running a "drush dl" command, if there's a composer.json shipped with the project, we could process it.

CommentFileSizeAuthor
#6 Screenshot.png89 KBrobloach
hook_drush_pm_post_download.patch865 bytesrobloach

Comments

patcon’s picture

patcon commented

What?! drush has hooks?? I had no idea. This is rocking my world.

I am so excited about EVERYTHING COMPOSER-RELATED!

patcon’s picture

patcon commented

I don't suppose you could explain more fully the limitation that you mentioned on IRC?

patcon’s picture

patcon commented
Issue tags: +Composer

tagging.

EDIT: ha. oh. yeah -- composer issue queue. guess that's not too useful :/

robloach’s picture

robloach
he/him
commented

Why not a composer tag for it, haha.

So, let's say you have mymodule...

mymodule/mymodule.module
mymodule/mymodule.info
mymodule/composer.json

When you run cd sites/all/modules/mymodule && drush composer install, it will install the package, and give you mymodule/vendor/autoload.php. Out of the box, mymodule does not load autoload.php. Would be neat if it was handled for us somehow though. Maybe that's up to mymodule to figure out!

Grayside’s picture

Grayside commented

A heavier approach would be for this project (or a companion project) to come with an autoloader for the auto-loaders.

However, the idea I was originally brewing with #1586446: [META] Composer-Drush integration ideas was to find a way to centrally manage externally downloaded dependencies. If three modules all want to install tinymce, shouldn't we try to reuse the same code?

robloach’s picture

robloach
he/him
commented
Status: Needs review » Fixed
StatusFileSize
new Screenshot.png89 KB

Committed, with some additional fixes. Does not conflict with #1586446: [META] Composer-Drush integration ideas at all, although it would help it! :-)

Grayside’s picture

Grayside commented

That looks really sweet.

Automatically closed -- issue fixed for 2 weeks with no activity.