Install Profile

[RobLoach]

No description provided.

[RobLoach]

Rather than a Install Profile, may be better to use a set of default configs for each component. Then you can pick and choose features.

[mikemccaffrey]

I've gone ahead and created the install profile. All it basically does right now is install the modules that have been included in composer.json, and also a sane selection of core modules.

Anya worries that we might have maintenance issues when installing a site using a custom install profile. I've certainly seen that cause problems for teams in the past, but they all seemed to be trying to use them for more complicated processes than just as an initial install. We should research if that actually does cause a problem of some sort, as I was unable to find anything with a cursory search.

We also need to figure out how to set some config variables on install, but with install profiles you are limited to either providing a config directory or using a profile.install file. We should figure out which is the most maintainable way to make a limited number of config changes without including too much cruft or dealing with schema mismatches in the future.

[RobLoach]

We can have the Install Profile provide the absolute basics, and then shift the optional default configs where applicable.

[mikemccaffrey]

I would like the install profile to make some common configuration changes, just so we can be sure that they are not missed when importing any optional configs files.

My preference would be to make the changes programmatically, so that we can have a laser-focus on just the attributes that we are looking to change, along with properly commenting the reasons that we are making those settings changes.

Here is what it looks like to have an install function setting configuration for the install profile:
https://github.com/kalamuna/drupal-project/blob/master/assets/install_profile.install

The config files concern me because they seem a bit more difficult to maintain over the long term, since they would need to be exported regularly to avoid problems with any schema changes that are introduced as modules are updated. And that exporting process still requires manual stripping of UUIDS and hashes that are site-specific, which seems like a time-intensive process that could be prone to errors.