Simplification ideas for site aliases and backend.inc

[weitzman]

• Remove concurrency
• Remove shell alias replacements, e.g. {{@target}} - Remove shell alias replacements #1369.
• Remove site alias lists, e.g. @foo,@bar
• Remove 'parent' inheritance in site aliases - Add a hook_drush_sitealias_alter, with documentation. #1279
• Remove relative aliases @site/@peer. db8166d
• Add an alter hook, so aliases can be adjusted in a policy file.
• Change site aliases to .yml. Dynamic changes still possible with hook_sitealias_alter. Segregate config, site selection (root+uri), and other parts of the array better. Replace array with one or more objects. - Convert alias files to .yaml #1609
• Refactor remote sites to be a first class object that gets passed around. Distinct from drush_get_option()

[kenorb]

I'm against removing concurrency for make, as it speeds up the make building 4-8x times (5min instead of 20min, e.g. in Travis CI). Used e.g. in: https://github.com/mycognitive/ads/blob/master/build.xml#L78
What would be the alternative apart of the hacks?

Site lists you mean site-list and invoke-multiple or configuration such as dev, test and live in files server-1.aliases.drushrc.php, server-2, etc. Then when you want to run the same command on all your dev servers you use @dev alias (e.g. for module, core upgrade or some other quick-fix).

What would be alternative to inheritance (@parent) of shared/common options from separate files?

Can you elaborate on removing @site.live@dev, what is that?

[weitzman]

The motivation to remove all these features is that they complicate Drush to the point where only one person ever contributes and maintains to backend.inc and sitealias.inc. Thats a big problem, and don't think "I'm against removing concurrency" is a full consideration of the risks/benefits.

One alternative for make is to take advantage of Drush's file cache. You can get that by persisting builds in the paid version of Travis. We could also email Travis about proxy caching ftp.drupal.org for us.

Instead of site alias lists, you could roll your own inheritance and merging of site alias properties using the hook that happens after yml is parsed.

[esolitos]

Hi @weitzman I'm with @kenorb on the concurrency, id doesn't only speed up the make command, but it's (currently) also the only way to avoid issues with large make-files, see #985.

PS: Thanks for your efforts on drush!

[weitzman]

@esolitos - thats just a make bug that anyone can fix. we aren't going to architect Drush around a bug thats easily resolved.

[greg-1-anderson]

I am thinking we should make these changes in master, after we have spun off Drush 7, rather than try to make these changes at this time.

[ergonlogic]

In Aegir and a number of related projects, we use much of backend.inc extensively. I'm all for simplifying it as much as possible.

In core, concurrency only appears to be used by make. We could move the relevant logic over there in a simplified manner, presumably. Are there any other projects that we know of making extensive use of concurrency (or the other proposed removals, for that matter)?

More OOP, YML and support for remote sites will benefit just about all the projects I'm working on.

[greg-1-anderson]

@juampy72 recently used concurrency in one of his projects.

[juampynr]

This command uses drush_invoke_concurrent() when GNU-parallel is not
available: http://drupal.org/project/syncdb.

http://drupal.org/project/concurrent_queue uses it too.
On Jan 31, 2015 4:02 PM, "Greg Anderson" notifications@github.com wrote:

@juampy72 https://github.com/juampy72 recently used concurrency in one
of his projects.

—
Reply to this email directly or view it on GitHub
#975 (comment).