Hello @regis, thanks so much for the reply! I completely understand this position. Ultimately, keeping Tutor deployments as close to standard as possible is a major benefit for sanity and usability.
I do have a couple of additional pieces of information to add which might help to explain the rationale of the plugin.
First and foremost, the plugin was motivated by a desire to more easily change Edx app configuration and settings (l/cms.env.json and the settings.py files). It is certainly possible to affect these using template patches. However, especially for the *.env.json files, it felt to me that templating with Jinja wasn’t the best tool for my use-case.
If many plugins attempt to patch these files, it was hard for me to conceptualize how each plugin would interact. So, instead, I chose an approach that works like a dictionary “update”. Currently, only one such update can be applied (per the contents of a user’s
env_overrides directory), though I’ve tentatively planned to add the ability to “stack” updates (and entire override directories) in a user-defined order.
Another point to note is that a user’s environment modifications are fully contained within their
env_overrides directory. So, when maintaining modifications, only this folder needs to be checked into version control. I’ve also been planning to allow all such modifications to be “compactified” into a single file for production.
On the other hand, if a template is overridden, it is true that the user is now effectively responsible for maintaining a Tutor fork. I’d like to make it more clear that this should really be used as a last-resort option for admins with tight constraints on their deployment’s spec. Such admins will need to be willing to maintain these changes as Tutor makes changes prior to upgrading their platform.
It is still true, though, that only the env_overrides folder, which might include redefinitions of Tutor templates, needs to be tracked for this fork(-like repository).
To make tracking less difficult for overrides containing templates, I’ve toyed with a few different ideas. One is that overrides with template changes should have the ability to declare the version of Tutor with which the override is compatible. Prior to incrementing the version, the maintainer will need to ensure that the override is still compatible.
One way that recon can assist with this is to add an interactive merge feature that works by the individual template. Of course, simply merging Tutor’s template changes into your overrides, even if only through fast-forwarding, is not enough to guarantee that the plugin would still work. So active maintenance is required regardless.
In retrospect, overriding of settings and overriding of templates are two fairly distinct features though they can go hand-in-hand. The ability to define a way to combine multiple sets of overrides will be needed to allow these features to operate more independently. And the documentation should make the differences clear.
All in all, the hope is to make it straightforward to ‘resolve’ a stack of overrides. Once fully resolved, all overrides could be compacted into a “single source of truth” file which should be human-readable. Even templates could be included as strings in such a file. Meanwhile, the Tutor installation on a node can be left vanilla or can begin with traditional plugins (with the knowledge that any override in the final, resolved file takes highest precedence).
As for a move to using only Caddy, this looks like a great idea! Please let me know if I can assist with the contribution. This is definitely a circumstance where a contribution makes the most sense, and I look forward to the added simplicity .