I would like to use the Drush package manager to quickly update modules that are included through symbolic links. Basically, I have a local repository of modules in /var/www/drupal/contrib/modules. Each user/client gets their own install of Drupal in their home directory, and then can symlink to modules in the repository (by putting links in /home/user1/drupal/sites/all/modules). This is nice because it eliminates duplicated code (the same module installed on multiple sites), and I can maintain and update modules for all clients in one location. However, I have to manually drop new modules in /var/www/drupal/contrib/modules, whereas I'd prefer to be able to just run a command like "drush up" to update the modules in the repository.

Any ideas on how to accomplish this? If I "drush up" from within a Drupal install to update a module, it actually deletes the symlink to the module and replaces it with a full local copy of it - not what I'd prefer. So if I could somehow force Drush to follow symlinks and update the module sources that would be nice. Another option would be if Drush could scan a directory of modules (even if they are not in a Drupal install) and update them - effectively updating the whole repository at its source. Some have proposed having a "master install" of Drupal and making that the repository, and running drush up on that, but that has the disadvantage of having to make sure that all modules are enabled in the Drupal install in addition to being present on disk.

Comments

danepowell’s picture

danepowell commented

Another viable option would be to force Drush to ignore symlinks altogether, so that I can symlink to modules in the repository that I want to keep under version control and update manually, but have Drush update all other modules that will be stored locally for each site (this leads to wasted space from file duplications, but that's not too huge of an issue I suppose).

greg.1.anderson’s picture

greg.1.anderson commented

The very first thing you need to be aware of is that the weakness of your scheme is that after you pm-updatecode one shared module, you need to do an updatedb on all of the different Drupal sites that use it.

If you're cool with that, I would recommend that you configure a vestigual Drupal site at /var/www/drupal, and put the modules at sites/all/modules as usual instead of putting them at contrib/modules, and enable the union of all modules on your proto-site. Then you can pm-updatecode on your proto-site, and all of the other sites that simlink into it will immediately get the new code (potentially breaking them, until updatedb is run on their databases).

Alternately, you might just consider using Aegir.

danepowell’s picture

danepowell commented

Thanks- the proto-site solution does seem like a good one and I'll probably try that out. (FYI, in reality, I wouldn't run drush up directly, but in a script that also runs updatedb on each site)

I'd LOVE to use Aegir but haven't figured out two things, which actually relate to this issue: (1) how to get it working with this directory structure - that is, how would I run a multi-site install in /var/aegir/ while actually storing the sites in /home/user1/drupal? Symlinks are the obvious answer, hence this issue; and (2) how to configure the permissions in a sensible way for a production server hosting multiple clients (see http://groups.drupal.org/node/43910)

greg.1.anderson’s picture

greg.1.anderson commented

Well, I don't think I would try to make Aegir work with that directory structure. Based on #769264: have a whitelist of modules to bootstrap commandfiles and drupal code, I know that anarcat is working on configuring permissions so that multiple clients can share drupal instances in a secure way. You want to be careful about this; don't let the users run cron tasks on code they control except with the permissions of their user account, for example. I haven't tried to work out these issues myself, though. All my sites run dedicated.

danepowell’s picture

danepowell commented

Actually, while the proto-site solution is working for me at the moment, I can envision having problems in the future. For instance, if any two modules conflict then they can't be managed this way (since they both have to be enabled on the proto-site to be updated). If I need to maintain multiple versions of a module simultaneously, that's also not possible. So I still think it would be useful to get Drush to follow symlinks or act on a "dry" directory of modules (outside of a Drupal install).

greg.1.anderson’s picture

greg.1.anderson commented
Category: support » feature

True. Not so important for me, but perhaps someone who wants to run this way will pull together a patch.

danepowell’s picture

danepowell commented
Title: Package management with symlinked modules / outside of a Drupal install » Package management outside of a Drupal install

Actually I have run into just such a problem - I need to "freeze" a module and keep it from being updated, but I can't disable it on the proto-site because another module that I do want to stay updated depends on it.

So yeah... being able to manage a directory of modules outside of a Drupal install would be a huge help :) But I understand if this isn't a high priority considering how difficult it would be, since the package manager relies on a lot of core functions like update_refresh

moshe weitzman’s picture

moshe weitzman commented
Priority: Normal » Minor

It is plausible for Drupal 8 that we abstract the package manager out of Drupal, or make it more easily reusable. IMO it would be a good plan. Until then, not much priority here.

Interested parties might want to chime in at http://groups.drupal.org/node/21295

danepowell’s picture

danepowell commented

FWIW, once I took another look at the situation the "proto-site" solution ended up working pretty well for me: Manage multiple Drupal sites efficiently using Drush and "proto-sites"

greg.1.anderson’s picture

greg.1.anderson commented

Regarding this comment from your blog:

I want to use the drush scripts to quickly update stock modules en masse, but I need to use SVN and vendor branching to update the patched ones. Unfortunately, there's no way to discriminate between the two when they're all sitting in the same directory on a proto-site...

You could try using the new locking mechanism in pm-updatecode from #446736: Have drush update be told to ignore a module/theme -- simple solution to lock all of the patched modules. I'm planning on making a hook in the Hacked! module that auto-locks patched modules; if you lock them with drush, you can put in a comment that says why you're locking it; you'll see that comment every time you run pm-updatecode. This is assuming you're on drush-HEAD; that feature isn't in 3.3.

danepowell’s picture

danepowell commented

Oh wow, that auto-locking feature sounds amazing- thanks!

greg.1.anderson’s picture

greg.1.anderson commented

Okay, but only because you said it sounded amazing...

#886358: hacked-lock-modified

danepowell’s picture

danepowell commented
Component: Code » PM (dl, en, up ...)
Status: Active » Closed (won't fix)

I've since been able to achieve most of what I desired using (at first) the --lock-modified switch, and more recently a combination of Aegir and Drush Make, so this isn't really an issue for me any more. Thanks!