[DEPR] Remove the unnecessary themes

[MaferMazu]

Proposal Date

Oct 1, 2024

Ticket Acceptance Date

21 Oct 2024

Technology Removal Date

21 - 31 Oct 2024

Earliest Open edX Named Release Without This Functionality

Sumac - 2024-10

Rationale

• We no longer use bragi-generator themes since Nutmeg.
• We can use bragi-children/css-runtime.

Removal

• edx-platform/bragi-generator
• bragi-children/espol/lms
• bragi-children/sports/lms
• bragi-children/suss/lms

Replacement

bragi-children/css-runtime

Additional Info

Initial idea comes from: https://github.com/eduNEXT/eox-release/issues/136#issuecomment-2368836585

Task List

• Remove the directory edx-platform/bragi-generator from the master.
• Remove the bragi-children espol, sports and suss.

[MaferMazu]

Can we DEPR the espol, sports, and suss themes? I want your insight to know if it makes sense. If not, I can change the scope to only deprecate the bragi-generator directory.

cc @DonatoBD @Albeiro514

[MoisesGSalas]

I think this should we weighted alongside a deprecation for eox-theming.

From what I understand eox-theming provides two main features: The multi-level template inheritance and the extra_scripts context processor. If we are only using the css-runtime children then I don't think the former is too valuable. About the latter, I don't know how is its current state, but I think is not being used by the stratus clients, and needs a replacement in an MFE world.

If we are not really using the features on the plugin then it makes sense to drop support for future releases and make few adjustments to have less code to mantain.

[felipemontoya]

I think this should we weighted alongside a deprecation for eox-theming.

I don't think it is so easy. I would love it if we could deprecate themes and eox-theming, but control center for stratus installs expects bragi to exist and bragi requires eox-theming.

1. suss and sports I believe are easy to remove. Basically they are living in the saas and thus will not migrate in the same form out of nutmeg.

2. bragi-generator we can remove once we confirm that no single stratus install is using that.

3. to fully remove espol we need a solution in the "hosting-core" product to keep theming as part of the customers data.

My take on this DEPR is that we can go for 1) and try to at least track how many installs are using 2). I would leave 3 for after we have a clear roadmap for hosting-core.

** hosting-core: the hosting that uses k8s namespaces instead of eox_tenant for each customer and is quick to create/destroy an independent install.

[MoisesGSalas]

Isn't mainly the need for eox-theming from bragi the use of the ThemingConfiguration helper? I think this can be replaced with a helper in eox-tenant.

How come the theming isn't part of the customer data at the moment when the configuration is stored in the database as part of the TenantConfig?

[DonatoBD]

Hi hi, srry for the delay. I’ve looked into this and I would say there’s no issue with removing both bragi-generator and bragi-children. Primarily because for Stratus customers, we use css-runtime, and SaaS customers will remain on nutmeg.

Regarding eox-theming, it seems very logical to propose deprecating it as well and leaving that small functionality within another plugin, but I would say that this conversation would make more sense as a decision for the hosting division

[MaferMazu]

Thanks, @DonatoBD, for clarifying this.

Considering what we discuss here, we will remove the bragi-generator and bragi-childrens (maintaining css-runtime), open a DEPR proposal about eox-theming, and let the hosting division discuss it and analyze the implications.

I'll change the status of this deprecation to Approved and let this issue open until we deprecate the themes.

Thank you all for the insights ✨