Problem/Motivation
Nesting contrib projects (e.g. modules, themes) inside other contrib projects (e.g. install profile) makes managing project in a site repo and contributing changes overly complicated. We can reduce friction for maintainers and contributors by NOT nesting contrib projects inside other contrib projects. This way, developers can work in a parent site repo, then use git-subtree, git submodules, or git subtree merge to break out work done in a site repo and push it out to drupal.org project repos.
Proposed resolution
Drush 7 now supports this contrib_destination property. Initially the solution proposed here was to get drupalorg_drush updated to run on Drush 7.x (master). This is now seeming overly complicated. A simpler, faster path forward is to backport Drush support for the contrib_destination property to Drush 5.x and 6.x. Then update drupalorg_drush (now on 5.x) to use a newer version.
Remaining tasks
- Drush 6.x support for contrib_destination property, https://github.com/drush-ops/drush/issues/834
- Drush 5.x support for contrib_destination property, https://github.com/drush-ops/drush/issues/836
- Update drupal.org server to use a version of drush including either of these patches ^^.
Comment | File | Size | Author |
---|---|---|---|
#3 | 2281721-support-contrib_destination.patch | 1.02 KB | bryanhirsch |
Comments
Comment #1
bryanhirsch CreditAttribution: bryanhirsch commentedDrush Make seems solid for use as of commit 71305b7.
All automated tests are passing as of commit 71305b7 (HEAD):
https://travis-ci.org/drush-ops/drush/builds/26964694
https://github.com/drush-ops/drush/tree/master-fulltest
Anecdotally, I've been using the Drush master (7.x) branch for make builds for months and haven't had any problems.
Comment #2
bryanhirsch CreditAttribution: bryanhirsch commentedComment #3
bryanhirsch CreditAttribution: bryanhirsch commentedHere's a patch for drupalorg.
Comment #4
dwwI don't fully understand what this issue is proposing to change.
The only "nesting" going on is either caused by:
A) The packaging script creating full tarballs which are supposed to be easy for end users to download and install without knowing about package management tools, running drush make themselves, etc. These are a whole "site in a tarball", including the distro, core, all modules/themes, just as a tarball, without git anywhere to be seen.
B) Distribution maintainers Doing It Wrong(tm). See #2153139: Unpublish Distributions with Forks of Core < 7.32
If a developer/contributor wants to do things with a more fancy workflow involving site repos and git sub(trees|module)s, they can/should run drush make themselves, can use whatever version of drush and its features they want. But our packaging script definitely isn't setting up git at all, so I don't see why we need to do this.
Can you please explain?
Thanks!
-Derek
Comment #5
bryanhirsch CreditAttribution: bryanhirsch commentedComment #6
bryanhirsch CreditAttribution: bryanhirsch commentedComment #7
drummRegardless, upgrading the drush version used for packaging distros is good to do. This should either be merged into #1854444: Upgrade drush used for distro packaging with drush make, or close that in favor of this issue since it has more recent information.
The next step will be updating our Puppet module that installs drush & other packaging requirements. We will want both installed in parallel, while we try out staging/dev.
Comment #8
bryanhirsch CreditAttribution: bryanhirsch commented@dww, thanks for the question. I had posted a detailed response, but it's verbose and I think it makes this ticket inaccessible. I have moved the verbose answer to this gist for people interested in the user stories, options, and background on the conclusion:
https://gist.github.com/bryanhirsch/a3e29e945d087a02affe
Hoping we can get this issue moving forward again to get this issue unstuck.
Comment #9
bryanhirsch CreditAttribution: bryanhirsch commentedIt's now seeming to me like the path of least resistance is actually to backport support for contrib_destination to Drush 6.x and 5.x (a tiny, simple patch). Then update drupal.org to use Drush 5.x (the version currently being used) with support for contrib_destination.
Here are the related issues and pull requests I filed for Drush to backport support for the contrib_destination property:
6.x, https://github.com/drush-ops/drush/issues/834
5.x, https://github.com/drush-ops/drush/issues/836
Comment #10
drummNow that drush make files can be YML formatted, this is causing more friction for distribution maintainers.
Comment #11
drummI tested drupalorg_drush out with Drush 9 and managed to get tests passing without substantive code changes.
Comment #12
drummWe’ve been using Drush 8.1.3 to build & deploy *.Drupal.org sites for a couple weeks and everything is working well. There were some minor changes in info file formatting, but nothing major.
The remaining work here is to get drush with drupalorg_drush set up in Puppet, alongside the old drush in case we have to switch back; then switch the packaging script to use the new path.
Comment #13
drummFinally going to do this.
Comment #14
drummAll my testing shows this is ready to deploy, which should happen within the next hour.
Comment #16
drummDone - Drupal.org packaging now has Drush 8.1.12