Use case:
I'm setting up a makefile for us to use to spin off a new "empty" site. It includes the usual assortment of standard modules, which download to sites/all by default. This is good. It includes our base theme (Zen) which downloads to sites/all. This is good.

It also includes a copy of the Zen Starterkit theme that we then customize for each site. This gets downloaded to sites/all, rather than sites/default where it belongs as it is site-specific. This is not good.

I have so far been unable to find any way to coax Drush into downloading just one project to sites/default rather than sites/all. I've tried hacking around with destination, contrib_destination, base_contrib_destination, directory_name, and whatever else I can find. Drush keeps overwriting those with sites/all again. Relative paths don't work either. I also tried setting up a second makefile to run with --no-core that just downloads that one project. Still no go. Instead I just kept getting errors that the directory already exists, so the secondary makefile doesn't do anything.

Some supported way of doing this would be really nice or at least some way to hack the config into making it possible. (A supported way would be better, though.)

Comments

dmitrig01’s picture

dmitrig01 commented
Version: 6.x-2.0-beta8 » 6.x-2.x-dev

the issue wih this is the fact that there are multiple ways you can build a makefile: for example, calling --contrib-destination . in sites/all should work the same as calling --contrib-destination=sites/all in the root. additionally, with the current system you can build a sites-specific makefile as a profile without changing anything

Crell’s picture

Crell commented

What about allowing a project definition to specify keys that get otherwise derived (contrib_destination, etc.)? That would at least allow edge cases (which I admit my case may be) to vary download behavior if the developer knows what he's doing. In my case the makefile is run by an automation script (also in drush) that explicitly sets the path that the command runs from and saves to, so I know it's "safe".

dmitrig01’s picture

dmitrig01 commented
Status: Active » Closed (duplicate)

Technically the other is a dupe of this but there's been more action there: #913148: Please bring back install_path