Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Make Islandora a Drupal distribution #1194

Closed
dannylamb opened this issue Jun 27, 2019 · 10 comments
Closed

Make Islandora a Drupal distribution #1194

dannylamb opened this issue Jun 27, 2019 · 10 comments
Assignees
Labels
Subject: Ansible Playbook Related to the maintenance and upkeep associated with an Ansible Playbook for Islandora. Always also

Comments

@dannylamb
Copy link
Contributor

We've talked about this a lot, and it seems like a great way to package up all of our Drupal modules for people. Let's make an Islandora distribution with a curated list of features you can get from our code + third party modules. We can even do things like make sub-profiles and create IR or RDM or other variant distributions for specific purposes.

@bryjbrown
Copy link
Member

I think Drupal distributions and installation profiles are pretty similar, and I recently ran into some issues with building a D8 installation profile with the project I'm currently working on. An installation profile (and a distribution as well) defines what modules are installed and holds extra configuration states for the site, but you don't specify the version number in the installation profile/distribution and this can lead to problems if the version number changes something because you can end up installing a newer version of a module that doesn't conform to your configuration state. For example, we are using the Group module, and when it upgraded from 8.x-1.0-rc2 to 8.x-1.0-rc3 it added a dependency for the Entity module. While composer could account for this, Drupal could not because now an older module depends on the presence of a newer module that isn't accounted for in the configuration, causing it not to validate and for the entire Drupal installation to fail when building from that installation profile. Ideally we should have been able to control this by specifying a static version via Composer, but since all the Group release candidates are technically "1.0", we couldn't tell it to grab the previous version. We ended up rebuilding our deployment scripts to use Drupal console to manually install & enable modules and import configurations as separate steps so that we have more control over the process.

This is not to say that installation profiles/distributions are bad, but they are fairly new and have a bit of an unstable and not very well documented API underneath that makes things tricky. I'm trying to brain dump the issues we've had in this thread so that people are aware of them as they begin work on this.

@dannylamb
Copy link
Contributor Author

Awesome, thanks for the heads up @bryjbrown . That's definitely a bear trap to consider.

@alxp
Copy link
Contributor

alxp commented Jul 3, 2019

Acquia lightning sub-profiles: https://docs.acquia.com/lightning/subprofile/

@alxp
Copy link
Contributor

alxp commented Jul 3, 2019

And here's how Lightning packages up their distort so that it is controlled by composer, which handles the version updates: https://github.com/acquia/lightning-project

@bryjbrown
Copy link
Member

Revisiting this, I think that packaging Islandora 8 as a distribution is not only a great idea, but would allow us to package special versions of Islandora 8 as well via sub-profiles as @alxp said above. There are a lot of possibilities for this, but the one most on my mind is an IR distribution. During installation of the Islandora 8 distribution users could select which installation profile/sub-profile they want to use (very similar to the way Drupal 8 sites ask if users want the "Standard" or "Minimal" install). Folks could install a "Minimal" Islandora 8 instance with only the basics, or they could choose the "Institutional Repository" option and get a ton of extra IR stuff. You could do something similar for Digital Archives too.

@dannylamb
Copy link
Contributor Author

We'll be evaluating an install profile by Born Digital created for Whitman College as part of their migration project into Islandora 8. I'm hoping we can use this ticket to track that work without creating a new one.

@alxp
Copy link
Contributor

alxp commented Apr 14, 2021

The Lightning project did a lot of work to make composer be able to version requirements of a Drupal profile.

Here's a starting point for a distribution that uses composer to keep track of versions and releases, and downloads the profile with all the profile's dependencies in its own composer.json which is read recursively:

The sample profile I made for Islandora is just a starting point, it's listed as a sub-profile of Lightning now but that doesn't need to stay the case / really affect anything if you don't use its features.

https://github.com/roblib/islandora-project

@DonRichards
Copy link
Member

@alxp Thanks for this!!

@dannylamb
Copy link
Contributor Author

Duuuuuuuude awesome! Thanks @alxp

@adam-vessey
Copy link
Contributor

We eventually moved to roll a "Starter site", as more of a template project: https://github.com/Islandora-Devops/islandora-starter-site

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Subject: Ansible Playbook Related to the maintenance and upkeep associated with an Ansible Playbook for Islandora. Always also
Projects
Development

No branches or pull requests

6 participants