drush downloads modules to "wrong" directory [#1587346]

Hey,

when using drush to download modules these are downloaded to sites/all which isn't that nice for migrating sites etc. I use the clients system account.

cheers Volkan

ps: i know that i could use: --use-site-dir but when dependencies are downloaded on "enable" these getting to sites/all too.

Comments

Comment #1

omega8cc CreditAttribution: omega8cc commented 17 May 2012 at 14:51

Status:

Active

» Closed (won't fix)

This is unrelated to BOA. Please consult drush docs and issue queue.

Comment #2

muschpusch CreditAttribution: muschpusch commented 18 May 2012 at 11:05

just for for other people looking for this. Put this in your drushrc.php

$options['use-site-dir'] = TRUE;

Here is the why: #1320266: Drush DL directory / set $options['use-site-dir'] even though i disagree with mig5 because not everybody has the luxury to create install profiles for all his sites..

Comment #3

omega8cc CreditAttribution: omega8cc commented 18 May 2012 at 11:52

Note that using sites/domain specific space for modules/code is a perfect recipe for disaster.

Comment #4

muschpusch CreditAttribution: muschpusch commented 18 May 2012 at 15:18

Hm... than i don't get your development workfkow... Do you really create an install profile for every site or am i missing something? Aegir isn't migrating sites/all/modules how is the migrated site being created? Do you have one site per platform?

Comment #5

omega8cc CreditAttribution: omega8cc commented 18 May 2012 at 15:48

It doesn't hurt to have some modules available but not enabled in every site, if they are used only in some other sites in the same platform. You should 'merge' as many sites with similar code base per platform as possible, to avoid code duplication, using either install profile space or platform space in sites/all. You don't need to create separate platforms for every site using some unique or patched code. Just create a separate install profile for every site really requiring its dedicated code space and use sites/all for all modules you can safely share between all sites in the same platform. It will allow Aegir to properly track all the code used and instead of the mess in the never-tracked sites/domain/modules space, you can still separate the code, but on the other end - in the install profiles, if you really need it.

Aegir migrates sites/domain directory only, while both platform specific and install profile specific space is, and should be independent of any site hosted.

You nay want to read and watch some video tutorials on this subject: http://omega8.cc/managing-your-code-in-the-aegir-style-110

Comment #6

muschpusch CreditAttribution: muschpusch commented 24 May 2012 at 12:30

The video's are really awesome! Thank you! But when best practice is to manage code in the "static" map in custom install profile platforms why are there all the default platforms? Just for testing and simple sites?

Comment #7

omega8cc CreditAttribution: omega8cc commented 24 May 2012 at 12:54

Using the ~/static directory is not a part or requirement of the best practices. It is useful/handy only when you are on the hosted Aegir service, so w/o any access to the profiles and drupal core in the default platforms or when you are creating platforms using custom makefiles, so you could easily purge any failed builds in the ~/static dir.

Octopus offers many platforms installed by default, because you should never really modify distros created by other devs (only add/override the code in the sites/all if needed) plus it is handy for most people who don't need/prefer using makefiles.