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.
Comment | File | Size | Author |
---|---|---|---|
#14 | drush-1452564-restrict-projects.patch | 7.26 KB | Steven Jones |
#9 | drush_make-1452564-9.patch | 5.68 KB | jamsilver |
#5 | drush_make-1452564-5.patch | 2.62 KB | jamsilver |
Comments
Comment #1
moshe weitzman CreditAttribution: moshe weitzman commentedWe'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.
Comment #2
Steven Jones CreditAttribution: Steven Jones commentedBut then you're not testing your make file, you're not checking that the patch you just added actually applies etc. etc.
Comment #3
dwwYeah, 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.
Comment #4
stevetweeddale CreditAttribution: stevetweeddale commentedI'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.
Comment #5
jamsilver CreditAttribution: jamsilver commentedI'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.
Comment #6
jamsilver CreditAttribution: jamsilver commentedComment #7
joestewart CreditAttribution: joestewart commentedPatch 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.
Comment #8
dwwFYI, 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...
Comment #9
jamsilver CreditAttribution: jamsilver commentedOK, 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
. I've done this for a few reasons:
a. Keep the main
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
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:
Comment #10
Steven Jones CreditAttribution: Steven Jones commentedI think this functionality needs some tests, which should be really easy to add I reckon.
Comment #11
dww- 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
Comment #12
dwwSide 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...
Comment #13
moshe weitzman CreditAttribution: moshe weitzman commentedNeeds tests and review by jhedstrom
Comment #14
Steven Jones CreditAttribution: Steven Jones commentedHere'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.
Comment #15
jhedstromThis 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.
Comment #16
moshe weitzman CreditAttribution: moshe weitzman commentedNice work Steven. Thanks for persisting with this.