Consider new types for DrupalInstaller? about installers HOT 8 CLOSED

Some other likely candidates would be:
drupal-drush --------> ~/.drush/{name}
drupal-profile --------> profiles/{name}

from installers.

~/.drush/{name} is good for dev environments but not as nice for servers.

If trying to bridge Drupal 6/Drupal 7 to the Composer world, the convention for third-party libraries? Seems painful to use Drupal-specific manifests...

drupal-library ----> sites/all/libraries

from installers.

Not sure about drupal-library as that's just a depending package (normal "library").

from installers.

I'm not against liberally adding types if they are useful. I imagine the likeliness of a conflict is low.

from installers.

drupal-drush --------> ~/.drush/{name}

Not sure how I feel about this one either. Seems to be mixing and matching philosophies. If Composer is following the lead of rubygems and npm, it would seem that it's aiming to put all dependencies (even development deps for tools) isolated into the project directory. (I realize that many sysadmins hate this approach, as it puts them out of the loop in vetting what are traditionally system-level tools. But I think it's an inevitable culture shift.)

For example, while they've been system-wide installs traditionally, Composer packaging philosophy puts PHPunit and PHP_CodeSniffer into the project directory itself. Shouldn't drush follow the same examples, leaving behind the idea of installing a single version of drush extensions (or even drush itself) for the whole system?

Tangent for Drupal peeps

Personally, I'm moving in the direction of keeping all build/test/deploy scripts and requirements in the repo with the code, and while I'm a fringe case, I think there's merit in this approach -- a build script at a given point in time (a given SHA1 commit hash) is only guaranteed to build the corresponding version of the site from that same point in time (hash), and will only be guaranteed to run correctly with a specific version of drush (as in, the drush version from composer.json at that hash). So to have a self-contained and totally version-controlled drupal site/project, the drush and dev tools versions should be project specific.

Am I talking crazy-talk here?

//cc @sdboyer (cause I know he's interested in this stuff)

from installers.

unfortunately, with the crappy typing we still have on drupal.org, it's tough to go much beyond module/theme. a special case could certainly be written for drush, and i think that makes sense, but there's no real way to do libraries that well, short of a simple whitelist.

generally speaking though, yeah, follow the drush make conventions.

from installers.

Not sure about drupal-library as that's just a depending package (normal "library").

Absolutely right. Which makes the broader form of my question "How can I get a D6 or D7 site to play nice with Composer and not manage external libraries in multiple ways."

drupal-drush --------> ~/.drush/{name}

Good location for a development environment, but not necessarily good for a server environment. We're headed towards having our own /etc/drush/drushrc.php file and pointing it to some other server location for commands and the like.

it would seem that it's aiming to put all dependencies (even development deps for tools) isolated into the project directory

This does seem like the standard that makes sense, but drush (at least) would need some different usage in mind. A "project context" lookup for a drush installation might do the trick. Take to the drush queue.

Personally, I'm moving in the direction of keeping all build/test/deploy scripts and requirements in the repo with the code [...]

We have done that (sans Drush itself) and are moving toward "paired" repo's, a "product" repo, a "tools" repo, and more general purpose "deploy/devops" repo. All three are tagged before a release. For us, the release cycle has various points of freeze which prevent us rolling out tools that would otherwise be useful and compatible.

from installers.

Hey guys! Just following up. Is there consensus on supporting any new Drupal types?

from installers.