Switching to drush make for installing Drupal modules and libraries

[lo5an]

If all of the Drupal modules and libraries, including Islandora, were installed in a single Drush makefile, that would give us a nice way to specify a particular Islandora configuration and share it with somebody.

[mjordan]

I have drush makefile here: https://github.com/mjordan/islandora_drush_make.

[ksclarke]

Integrated @mjordan 's drush make file in PR #44

[mjordan]

Can we close this issue?

[lo5an]

Looks good to me!

[lo5an]

Did this not work out? I was browsing through the code and it looks like the drush make stuff got reverted by a later commit.

[ksclarke]

I think reverting was a temporary measure to address some breakage. I'm hoping we can revisit the drush make approach after putting in place some tests (for instance, to check drush output for errors).

@ruebot So we should reopen this ticket? Or @lo5an if you can...

[ruebot]

I'm open to somebody tackling it again. But, I'm just curious as to what the advantage of using it is over cat'ing a list?

[lo5an]

Maybe we should make this an optional thing? Leave the existing, working mechanism in as the default?

From my perspective, I like that drush make handles both modules and libraries, and I like the level of control that it gives you over what's installed, and from where.

For example, if someone has a local variant of a solution pack they want to work on, or if they have a custom islandora module that needs a specific, known-working set of dependencies, then drush make gives them a nice way to specify those needs as part of the install process, down to the granularity of specific commits from specific repositories.

Also, I like that it's an off-the-shelf Drupal tool. It's hard to argue that anything is going to be more familiar to more people than a while loop in bash, but installing modules with drush make feels a little Drupalier :-)

[ruebot]

I guess I'm still confused. We just iterate over a list of Islandora Foundation modules, and then use drush to install those modules.

The way I understand it, is that a drush make file is just going to give you a list of things to download/clone, and then you still need to enable them, right? If so, that's what we're doing, iterating over a list, and using drush to enable all of those modules in the correct way. Some need to be enabled before others because of dependencies, and this should take care of that.

[lo5an]

Right. drush make doesn't, as far as I know, solve any issues having to do with dependencies and enabling modules. It would just make it more straightforward to do stuff like install a custom modules, switch to a local fork of a Foundation module, or pin a particular version of a Foundation module.

It might also be a good way to handle letting people switch between HEAD and the latest islandora release. We could have an islandora-1.5.make and an islandora-HEAD.make and people could set which one to use in configs/variables.

I've got some rainy day time this weekend, and I'm experimenting with an islandora_make.sh provisioner that I hope to make equivalent to islandora_modules.sh and islandora_libraries.sh.

[ruebot]

Cool. If you have ideas, go for it! 😄

[ksclarke]

Right, the make may not buy us much for an out of the box generic Islandora vagrant install for developers, but if we think about using the same scripts for a packer build (where there may be a desire for more customization) then I think it offers advantages. The HEAD vs. latest stable is one thing we're interested in, as well as being able to install a bunch of other drupal (or local) modules we want to use in our Islandora site.

Will look forward to your islandora_make.sh provisioner, @lo5an

[lo5an]

Working on things here.

Thoughts? Does this feel like a good candidate for an environment variable setting sort of thing? Or are people happy with just commenting in and out the appropriate couple of lines?

[ksclarke]

+1 to parameterizing rather than commenting in/out

[DonRichards]

I believe this should be closed. Not sure it is relevant any more. @lutaylor

[lutaylor]

@DonRichards I would be inclined to agree. We can re-open if necessary.