We wrote a small bit of code that gives the make command an extra couple of options:

  • projects
  • libraries

They take a comma separated list of projects or libraries to build from the make file.

So we can run something like this:

drush make profile.make --projects=views

And we just make the views project from the makefile. It will still apply any patches etc. This has made it incredibly easy to test changes to our make files as we don't need to sit there for ages while the entire thing rebuilds or comment out all the other entries and then un-comment when we've tested.

I'll post a patch in a bit, this is mostly here to remind me to do so.

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

moshe weitzman’s picture

We've added download cache and concurrency. The 'wait for ages' problem is mostly solved ... That command looks to me like a dupe of drush dl views. dl command takes a list of projects as well.

Steven Jones’s picture

But then you're not testing your make file, you're not checking that the patch you just added actually applies etc. etc.

dww’s picture

Yeah, this seems like a legit request. In fact, if we had this, it's possible the d.o packaging script would make use of it for certain things, too (although there might be other solutions to that particular problem -- stay tuned for an issue about this once we get a chance to write it up). Anyway, just registering my +1 here that I think this is a legit thing to want to be able to do during development, even given the download cache and concurrency.

stevetweeddale’s picture

I've been using the patch (yet to be posted) for the last couple of weeks, and it's really useful. One of those 'how did I live without this?' type things.

Having a build fail at some point down the line due to a silly make-file syntax error is kind of annoying. So running a local test make is necessary - especially if you're doing lots of interesting things like checking specific revisions out of a git repo (on github), then applying a patch. Also some modules look for libraries in weirdly named subdirectories etc - just re-running the relevant section, checking the result, repeating is the easiest way of getting things right. Running the whole make file is too slow at this point - so up until this point I would comment out everything else in the make file whilst adding new things.

jamsilver’s picture

FileSize
2.62 KB

I've attached a patch which achieves the desired functionality. Not saying it's the way to go, but it does the trick! It allows for the following usage:

# Only make views and ctools
$ drush make --projects="views,ctools"

# Make views,ctools and all libraries
$ drush make --projects="views,ctools" --libraries="*"

# Make only tinymce
$ drush make --libraries="tinymce"

# Make tinymce and all projects
$ drush make --libraries="tinymce" --projects="*"

The patch should apply against the latest dev.

jamsilver’s picture

Status: Active » Needs review
joestewart’s picture

Patch applied cleanly and worked as described. Yes, this will be helpful when building out makefiles and troubleshooting. thanks.

I didn't find the Libraries: None output to be needed but not a big deal to me.

Drush make restricted to the following entries:                                                                                                           [ok]
Projects: views
Libraries: <None>

Project views contains 2 modules: views_ui, views.
views-7.x-3.3 downloaded from http://ftp.drupal.org/files/projects/views-7.x-3.3.tar.gz                                                                   [ok]
dww’s picture

FYI, this might be a critical feature for the drupal.org packaging script depending on how we decide to fix #1455614: Packaging script doesn't allow distributions to patch core or specify a git revision...

jamsilver’s picture

FileSize
5.68 KB

OK, I've attached a new version of the patch with the following improvements:

1. Removed "Libraries/Projects: <None>" output as suggested by joestewart. I agree, it makes sense to list what _is_ included in the make, not what _isn't_.

2. Moved the logic into a utility function

make_prune_info_file()

. I've done this for a few reasons:
a. Keep the main

drush_make()

function nice and readable
b. Easy to re-use the pruning logic in different circumstances. For example when #1206340: introduce an options array in the root level of the makefile is resolved, it would be natural to expect to be able to put 'projects' and 'libraries' entries inside makefiles, which may see

make_prune_info_file()

being called from the DrushMakeProject::recurse() method.

3. Added the complimentary 'projects-exclude' and 'libraries-exclude' options, for the following reasons:
a. Completeness (is that a real reason :p?). Seems like it is likely to come in handy (e.g. build all projects except those I know come from GitHub).
b. From reading dww's #1455614: Packaging script doesn't allow distributions to patch core or specify a git revision - Option 2 looks like it may well benefit from usage such as the following:

# Build just drupal core
drush make --projects="drupal"

# Build everything except drupal core
drush make --projects-exclude="drupal"
Steven Jones’s picture

Issue tags: +Needs tests

I think this functionality needs some tests, which should be really easy to add I reckon.

dww’s picture

- Agreed this needs tests.
- For d.o packaging we don't need exclude since drush make already supports --no-core. So, while exclude might be useful for other reasons, we shouldn't add it for the d.o case. If there's no legitimate use case now, I'd vote we leave it out and keep it simple. Beware of YAGNI.

Thanks,
-Derek

dww’s picture

Side note: the d.o packaging problems got solved via other ways. So, I'm less urgently concerned about getting this in. I still think it's a useful feature, but I can't really spear-head the effort to drive this home...

moshe weitzman’s picture

Status: Needs review » Needs work

Needs tests and review by jhedstrom

Steven Jones’s picture

Status: Needs work » Needs review
FileSize
7.26 KB

Here's a patch that removes the extra 'exclude' stuff, which we don't really need I think, and adds some tests for the projects and libraries restrictions.

jhedstrom’s picture

Status: Needs review » Fixed

This looks good to me. Committed #14 with some small code formatting changes. I look forward to utilizing this new functionality for testing out patches, and adding single modules to .make files. Thanks all.

moshe weitzman’s picture

Nice work Steven. Thanks for persisting with this.

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