I have some use cases for Drubuntu that are not Ubuntu-specific, such as setting up certain git aliases, drushrc in home directory, and so forth. This got me thinking about some of the requests I've heard about breaking down drubuntu into different components. Add to that the problem of all the great stuff in Drubuntu that is paralyzed because as one large project it's got too narrow an audience to attract enough developers.

I'm thinking it would be useful to have:
- Drubuntu: Building out a basic development environment from a base ubuntu installation.
- Spinner*: Drush commands that facilitate easy creation of new development sites. Able to do more if using Drubuntu's setup.
- Dapper*: A Drupal "package management/installation" system for everything not a drush command or module. Which Drubuntu uses by implementing some engines.

* Names I thought of this morning.

Thoughts? I am prepared to spend time on "Dapper" if this sounds good. Also, I invite brainstorming on the names.

I am marking this as "Needs Review" because I am looking for another nomination or two before I approach things in this way.

Comments

Grayside’s picture

Grayside commented

BUMP, and just to say, I would also not want to hijack Owen's project without his approval, to say nothing of active participation!

owen barton’s picture

owen barton commented

This is an interesting idea for sure, and I think a good one. I think some of this could potentially go into Drush core as well. Could you give some examples of what you think might go into each project from a code/functionality point of view?

I have actually been wondering is there are ways we can better leverage the great work that has gone into the Quickstart project - it seems like we may be able to use it's bash scripts to do some of the legwork. The main question is how to make it configurable/selectable enough, since I think many people will want to skip/tweak stuff. We could then focus Drubuntu into providing the CLI UI for tuning the install, or something... haven't quite figured it out yet :)

Grayside’s picture

Grayside commented
Status: Needs review » Needs work

Continuing with the code names, and fleshing out my thoughts a bit...

Drubuntu
A series of engines for setting up the kinds of big things that people don't want to deal with, like webservers, IDEs, Browsers, basic tools of the trade.

All the engines currently in Drubuntu, implemented for Dapper. ($> drush dapper-install --package="apache", or for the indecisive, $> drush dapper-install www to get a list of server options.)

Also has any necessary bootstrapping so you can start with a bare Ubuntu install and get everything set up. There has been a couple people in the queue for whom any terminal work was getting fairly advanced, but they loved the idea of having a usable Ubuntu development environment.

Drubuntu now becomes really focused on being a Drupal-slanted LAMP+ stack installer for Ubuntu users.

Dapper
A engine manager (or better for user terminology, a package manager) that focuses on facilitating the creation of and user interaction with various packages such as the Drubuntu packages. While Drubuntu's packages are generally tied to Ubuntu, other kinds of "packages" could be created for installation into the user environment, such as git hook scripts, git aliases, drushrc file, and other tools that don't quite fit the drush pm system for commands and modules.

This is not intended to be a wrapper around traditional OS package managers, it remains a system by which developers can more easily build engines to distribute code or tools of interest. Key features include uninstallation of packages, showing lists of options, allowing users to install "suites" of packages, such as all the drubuntu engines ($>drush dapper-install --suite="drubuntu"), standardized backup system, and so forth.

It also tracks which packages/engines are currently active and makes this information available via a function call such as dapper_engine_is_active('drubuntu_apache2'), which other drush commands can use to adapt their behaviors to known environment configurations.

Spinner
The site creation tools from Drubuntu. Now structured to either implicitly (via careful hook usage) or explicitly (via overt engine checking) adapt to the user's development environment.

For example, a site-add command that creates a Drupal site, possibly using a specified installation profile or make file, and then either leaves it to DNSMasq to work the magic, or provisions /etc/hosts and the vhost configuration file for the new site.

A lot of the added value of this command over continuing to push the site-install command in Drush core is the environment-specific stuff which is determined in part by Dapper integration...

mlncn’s picture

mlncn commented

+1 to pretty much everything.

Grayside’s picture

Grayside commented

I thought of an interesting use case for Dapper.

  1. A dapper engine which configures nightly database dumps (setting up http://drewish.com/content/2010/03/using_logrotate_and_drush_to_backup_d... perhaps)
  2. An implementation of COMMANDFILE_drush_load() in the file COMMANDFILE.drush.load.inc that checks whether that package is installed.
  3. A drush command or command extension that loads a database by specifying a date as an argument.
Grayside’s picture

Grayside commented

So I've been re-thinking what I know of engines, and realized that since an engine type represents a set of mutually exclusive options, the engine system is not quite appropriate for a package system, which really just needs some sort of object-oriented hierarchy. What's really called for in this is something more like the ctools system for OO plugins. Not fully clear on the implications of this and whether that means there is no place for engines. Still thinking.