- 🇪🇸Spain akalam
The changes of this patch are part of the patch #95 at #3266057-95: Allow profiles to define a base/parent profile [continue of #1356276] →
Marking this issue as duplicated.
Some versions of the patch in #1356276: Allow profiles to define a base/parent profile → allowed profiles to exclude config or dependencies inherited from a base distro/profile. This functionality was controversial, and so was postponed into this follow-up issue in order to unblock that one.
From #1356276-376: Allow profiles to define a base/parent profile →
excluded_dependenciesandexcluded_themes... are extremely valuable in real-life scenarios. For example, in D7 we used Panopoly as a base profile. We needed our own specific implementation of the Ckeditor wysiwyg so did not want to include the module dependency to panopoly_wysiwyg. Also, we didn't need the overhead of panopoly_search. By allowing subprofiles to exclude module/theme dependencies it gives greater flexibility to subprofiles to not have to find strange workarounds to remove modules that have no application in their specific use case.Another example is if a parent profile has a specific module that loads in default content. This is important for doing demos, but in my client's project I want that excluded since it has no application to what I'm building. A distro may want "required" modules like that on install for that distro alone, but it's not actually required in my distro even though I'm using it the other as a base profile.
Some concerns about supporting this have been expressed:
From #1356276-375: Allow profiles to define a base/parent profile →
[This] violates the ideas of (1) security, (2) stability, (3) clear responsibilities, and (4) separation of concerns...
The fundamental idea of inheritance is aggregation of requirements. ... It is pretty hard to undo something a parent theme has set up – and it should be – because the whole point is that you want to use the parent theme's composition, configuration, and overall setup as a base for your own theme, including updates, upgrades, and upstream changes. If that isn't in line with your thinking, then you'd copy/fork the parent theme instead; simple as that.
"Inheritance" for install profiles just simply acts like "dependencies" for modules: In essence, it just ensures that profile A exists and is installed before profile B.
And that's literally all we should be shooting for here: Extending profile A with profile B. Just (1) extending its dependencies and (2) extending or overriding its configuration.
Anything else on top of that (blacklisting, reversing, muting, undoing, …) is not core material.
To be discussed.
None.
Override dependencies from the base profile using the syntax:
base profile:
name: BASE_PROFILE
excluded_dependencies:
- MODULE_NAME
excluded_themes:
- THEME_NAME
Closed: duplicate
10.1 ✨
The change is currently missing an automated test that fails when run with the original code, and succeeds when the bug has been fixed.
Not all content is available!
It's likely this issue predates Contrib.social: some issue and comment data are missing.
The changes of this patch are part of the patch #95 at
#3266057-95: Allow profiles to define a base/parent profile [continue of #1356276] →
Marking this issue as duplicated.