This is more of a brainstorm than a feature request, but I thought I'd post it anyway. What if we were to process a project's .make file after downloading a project via Drush? This means when you run drush dl, Drush could download all dependencies for the module, including all libraries required with the module.

Here's an example using the Symfony module...

$ drush dl symfony
Install location /var/www/drupal/7/sites/all/modules/symfony already exists. Do
you want to overwrite it? (y/n): y
Project symfony (7.x-1.0-alpha1) downloaded to sites/all/modules/symfony.         [success]
Processing symfony.make.                                                          [ok]
libraries module downloaded from http://ftp.drupal.org.                           [ok]
symfony downloaded from
http://symfony.com/download?v=Symfony_Standard_Vendors_2.0.7.zip.                 [ok]

As you can see, it not only downloads the Symfony Drupal module, but also its dependency on Libraries module, and the Symfony Framework itself. It does this because it processed symfony.make:

; ======================================
; Symfony
; ======================================

api = 2
core = 7.x


; ======================================
; Dependencies
; ======================================

projects[libraries] = 2


; ======================================
; Libraries
; ======================================

libraries[symfony][download][url] = http://symfony.com/download?v=Symfony_Standard_Vendors_2.0.7.zip
libraries[symfony][download][type] = get

Attached is an initial patch which makes Drush Make process the .make files after downloading the projects.

CommentFileSizeAuthor
#6 1371124.patch2.35 KBRobLoach
processmakedownloads.patch1.82 KBRobLoach
Support from Acquia helps fund testing for Drupal Acquia logo

Comments

greg.1.anderson’s picture

greg.1.anderson CreditAttribution: greg.1.anderson commented

Seems like a good idea to me in concept.

One thing to consider is, will this work correctly in all environments? One notable example is installation profiles, which will contain a profile.make, and perhaps a profile.make.bootstrap file. If the later exists but is not used, and we just run profile.make directly, then we will miss any drupal patches (and perhaps other stuff), the modules will end up in sites/all/modules instead of profiles/profile/modules. The right thing to do for profiles is to run the bootstrap file, which will take care of downloading the profile and running its makefile. I'm not sure if this means that we just skip running makefiles in profiles, or maybe we special-case them and offer to run the profile.make.bootstrap (after removing everything else that we just downloaded...?).

There may be other reasons to be cautious here. I seem to remember discussions along these lines in the past, but cannot remember any details or outcomes.

In any event, we should probably prompt before running the makefile.

joestewart’s picture

joestewart CreditAttribution: joestewart commented

not sure if this really applies or even differently, but keep in mind some previous recursion problems with project make files automatically being provided.

See #1103872: Change name of ckeditor.make to ckeditor.make.example for drush make module. adrinux had some issues in other projects as well.

greg.1.anderson’s picture

greg.1.anderson CreditAttribution: greg.1.anderson commented

Currently, we have no projects that use .make files as described in #0 (naturally -- new feature), but we do have projects that have .make files (profiles), and we have also seen (reference in #2) that arbitrarily adding .make files to projects can be harmful, or at least inconvenient.

It might be useful to have some mechanism where projects could define what their libraries are. These could even be stored in a make file, but I would propose that the name of the makefile should not be *.make, to avoid conflicts with the other uses of that makefiles are currently employed for. projectname.make.deps or projectname.make.libs, perhaps.

Projects already declare their module dependencies in their .info file, and Drush already makes a faltering attempt to download dependencies during pm-enable. If we solved the module-to-project mapping problem, then makefiles for module dependencies would not be necessary. Makefiles for library dependencies would still be interesting, though.

dww’s picture

dww
we/he/they
CreditAttribution: dww commented

If we solved the module-to-project mapping problem ...

In theory, that's what project_dependency solved. Sadly, in spite of months of encouragement in the other direction, that ended up being an entirely drupal.org-specific hack. So, it's basically impossible for me to now build anything on top of that in the Project* suite to take advantage of it. Instead, we get to continue to bloat the drupal.org-specific codebase if we want to use this data for anything else. But, that's where to look. There might already be an issue open about exposing its data via some kind of JSON interface, I dunno. I sadly had to stop following things when they decided to go off on their own...

That said, I'm pretty -1 on automatically invoking drush make on projects like this. I've never been a fan of drush make's recursive behavior in the first place, and this just seems like it's asking for trouble.

However, I do think it'd be nice to have modules with library dependencies start providing [module].make.lib or whatever files and document that the easiest way to get all the dependencies is to install drush and run "drush make foo.make.lib" or whatever. That does seem like a nice improvement for the UX of installing these modules (especially now that drush make is part of drush core).

dww’s picture

dww
we/he/they
CreditAttribution: dww commented

#1299332: Provide dependencies to external services like drush

RobLoach’s picture

RobLoach
he/him
CreditAttribution: RobLoach commented
FileSize
1371124.patch2.35 KB

One thing we should take into consideration here is the Drupal root directory. If you run this from somewhere other than a Drupal root, DRUPAL_ROOT does not exist, so it doesn't know where to install the dependencies.

That said, I'm pretty -1 on automatically invoking drush make on projects like this. I've never been a fan of drush make's recursive behavior in the first place, and this just seems like it's asking for trouble.

A confirmation message asking you whether or not to process the .make file definitely should be in there. Having recursive dependencies is critical though, as we want to uphold our own existing dependency tree.

However, I do think it'd be nice to have modules with library dependencies start providing [module].make.lib or whatever files and document that the easiest way to get all the dependencies is to install drush and run "drush make foo.make.lib" or whatever. That does seem like a nice improvement for the UX of installing these modules (especially now that drush make is part of drush core).

This is completely up to how Drush Make behaves, and how module maintainers use it. As for downloading libraries, I'd like to point you over to #542940: [meta] Support for downloading libraries via Composer. It uses Drush Make's download factory, but handles modules that use the Libraries API. Again, a somewhat separate issue as this is up to how Drush Make behaves.

moshe weitzman’s picture

moshe weitzman CreditAttribution: moshe weitzman commented

Or do we want projects to ship with composer.json files?

greg.1.anderson’s picture

greg.1.anderson CreditAttribution: greg.1.anderson commented
Version: » 8.x-6.x-dev
Status: Needs work » Closed (won't fix)
Issue tags: +Needs migration

This issue was marked closed (won't fix) because Drush has moved to Github.

If this feature is still desired, you may copy it to our Github project. For best results, create a Pull Request that has been updated for the master branch. Post a link here to the PR, and please also change the status of this issue to closed (duplicate).

Please ask support questions on Drupal Answers.