pm-download will happily create a second copy of a project in sites/all that already exists under an active profile directory

Code looks fine. But are we really supposed to be helping folks change code inside of /profiles. It seems to me that the only point of putting the code there is to signal to the admin that it is under the control of the distro. Overrides should probably go in sites dir. I'm not sure about this though. The philosophy of distros is not much cooked yet. Perhaps adrian could chime in here as he is the original architect of multi-site and install profiles.

Actually, I feel like the current behavior is a feature not a bug. Distros (including profiles/*) are "core", and we shouldn't hack them (unless the user explicitly asks drush to) - Drupal will nicely allow you to override core or profile modules by placing a copy in sites/*/modules, and I think we should promote that as best practice.

There is no such master document, nor even a master blog post nor twitter blurb. We're treading new ground here, despite the relative maturity of install profiles (since 5.x). Again, would be ideal if adrian chimed in here.

I might as well just state my POV that an install profile chooses to put its code into /profiles or /sites. When it chooses /profiles, it signals "Don't touch!". Or else whats the point of having both places? Given that, updatecode is probably incorrect to be touching code in /profiles. Problem is, thats where Acquia put their modules and folks get real pissy when drush doesn't work for them. Interesting, Open Atrium puts all modules in /sites.

Hello!

Seems to me that the point of having a distro's modules installed separately under /profiles is so you can distinguish between what modules came with the distro versus what you installed on top of it. I think it's a little bit of a step backwards, however, to keep drush from being able to apply some random necessary security update to a contributed module just because (a) that module happens to be part of a distro, and (b) the distro's distributors haven't yet come up with an all-encompassing new version that includes the security update.

Let me put it into a different perspective. Drupal core is Drupal core: it's a single, stable unit, well-tested and well-vetted, and none of its constituent modules ever get updated without the whole thing getting updated. Distributions are different. They're originally shipped as standalone, downloadable products, true …but they include a lot of contributed modules, which will release updates on their own schedule, independently of the distribution. That's very different from the core model. If one of those contributed modules (which, let's face it, are not always particularly reliable even in the best of cases) comes out with a critical security update, I'm not going to wait around for the distribution to test and release it as part of their own codebase: I'm going to update the thing right away, because it's a critical security update.

Because that's the practical reality of it (from my perspective), I do not consider anything under profiles/ to be in any way "core". It's just not as trustworthy. And if it's _not_ "core", then as far as I'm concerned drush should treat it the same way it treats any other contrib code.

Thanks!
Adam

i actually think drupal core should have profile/$profilename override things in sites/all.
as in more specific overrides least specific.

Also, i think we should avoid putting code somewhere where we can break multiple sites at the same time, which is why the
plugin manager in core only puts it in the sites dir.

I'm gonna mark this as by design as per mine and owen's comments. Distros that put stuff in /profiles need to ship with own instructions for how their users should do upgrades. It could be an atrium-updatecode command or something like that.

I'm not sure what the dl behavior should be in #3. Thats a separate issue though.

For sure, there is no perfect answer here.