Integration with local dev tools like Fetcher, Buck, and Kalabox [#2338299]

There is a whole ecosystem of local development tools now, mostly leveraging vagrant.

Fetcher
https://www.drupal.org/project/fetcher

Buck
https://www.drupal.org/project/buck

Kalabox
https://github.com/kalabox/kalabox
https://github.com/fluxsauce/switchboard

Let's figure out a way to support all of them. I have no experience actually using any of these three tools.

I bet they all use similar information, so we should figure out what that is and do what we can to keep it as simple and abstract as possible.

Comments

Comment #1

acouch CreditAttribution: acouch commented 15 September 2014 at 19:00

buck is extremely simple and small wrapper around drush commands. You have a .local, .dev, .test, .live, alias file and can grab a new version of a site on a given environment.

To create a new site locally you are just getting the site info and "git clone" + "drush rsync" + "drush sql-sync" + "create a vhost"

One of the pain-points it seems is making sure you have access to alias files or site instance information. Fetcher solves this much more eloquently by connecting to a web service. Pantheon has a drush command for automatically updating aliases. Recently we've been just including site alias files in our repos and auto-discovering them: https://gist.github.com/acouch/d9f3437eecd4ed472d38

Comment #2

pirog CreditAttribution: pirog commented 15 September 2014 at 19:54

I think this is a great initiative. Kalabox V2 will be using Docker instead of Vagrant but i think the concern is still generally applicable. That said, I'm not sure Kalabox fits into this grouping since its just a surfacing on top of tools like Fetcher and Buck. That said, for Kalabox V2 we've started a project with similar aims to this issue called switchboard which is maintained by @fluxsauce. https://github.com/fluxsauce/switchboard We hope to abstract it even more in the future.

I also know @joshk and @sdboyer expressed interest in working on a similar initiative so you might want to ping them on this too!

Comment #3

Jon Pugh

he/him

English

Newburgh, NY

CreditAttribution: Jon Pugh commented 16 September 2014 at 19:18

To create a new site locally you are just getting the site info

- acouch

The "site info" are the details I am interested in. Basically all hosting providers are offering drush aliases, but in slightly different ways. If we can define the site info needed for each of them, we can build a standard around it.

pirog: I met with fluxsauce in Austin and immediately forked switchboard to start work on getting it to work with Aegir. See https://github.com/fluxsauce/switchboard/pull/58

And yeah, it would be integration with Switchboard, but since Kalabox is a little more well known I'm going to leave it in the title. ;)

My feeling now is that all hosting providers provide drush aliases but in slightly different ways. And the multiple localhost tools all handle local drush aliases in different ways.

My goal here is to simply provide the data needed about the projects and their environments hosted on devshop server as a simple API access call.

Let's document the data model of each tool here.

I see this issue growing way out of scope of DevShop, because we should all be on board to building a common server API for ~~drupal~~ web apps, but devshop could be a great proving ground because we are still pre Beta ;)

Comment #4

Jon Pugh

he/him

English

Newburgh, NY

CreditAttribution: Jon Pugh commented 16 September 2014 at 19:19

Issue summary:

View changes

Comment #5

Jon Pugh

he/him

English

Newburgh, NY

CreditAttribution: Jon Pugh commented 16 September 2014 at 19:24

Also:

Fetcher solves this much more eloquently by connecting to a web service.

Exactly. So devshop can be that webservice alongside pantheon and acquia and omega.cc and...

We really really should just join forces behind a common tool, it would make this much easier since the differences are mostly in the hosting providers.

Hooking up multiple hosting providers to multiple localhost setups is proving to be a huge thought blocker on this whole evolution.

If we could remove the variants of localhost providers (or at least reduce them) and all work towards a common project, we could really make things so much easier for everyone.