使用不同的模板维护各种Flask安装

Question

我对这个话题进行了广泛的研究，但没有找到真正的结论性答案。不过，我确实遇到了一些可能的解决方案和我自己的解决方案，但我不确定它们是否完全是推荐的，甚至在长期的维护中是否可行

所以我的问题。假设我已经开发了一个核心的Flask应用程序，它将作为blog引擎或定制的CMS的关键部分。让我们把这个引擎命名为MyFlaskCore

MyFlaskCore可以作为应用程序的核心安装在完全独立的服务器上。让我们想象一下以下复杂性/大小：

|-- app
    |-- blueprint_one
            |-- __init__.py
            |-- views.py
            |-- forms.py
            |-- models.py
    |-- blueprint_two
            |-- __init__.py
            |-- views.py
            |-- forms.py
            |-- models.py
    |-- blueprint_three
            |-- __init__.py
            |-- views.py
            |-- forms.py
            |-- models.py
    |-- static
            |-- main.styles.scss
            |-- build
                   |-- main.bundle.css
    |-- templates
            |-- index.html
    |-- orm.py
    |-- database.py
    |-- config.py
    |-- __init__.py

这里的代码将通过Git进行维护。用户通过手动更新甚至自动更新服务可以通过git-pull获得更改。虽然这对我的问题是多余的，但它有助于理解上下文

这就是背景

接下来，假设MyFlaskCore引擎由四个不同的用户使用。这些消费者中的每一个都使用核心引擎为他们提供后端服务。这个本地安装永远不应该被使用者修改

然而，这些终端消费者中的每一个都将被提供基本的入门模板，但是这些模板将由每个消费者根据自己的意愿进行修改和个性化。在搜索之后，我找到了几种方法来实现这一目标：

1. 使用git子模块维护将引擎添加为依赖项的存储库
2. 正在删除模板目录或文件上的Git索引[Git update index--假定模板未更改]
3. 我自己可能的解决方案是使用来自应用程序目录之外的位置的模板。例如，应用程序存储库根目录中的实例文件夹。如果找到本地模板，这将覆盖现有的基础模板
4. 从外部资源或服务呈现模板字符串。我个人认为这会增加不必要的集成开销
5. 将模板存储在数据库中

以上每种解决方案都提供了一种独特的方法，但我觉得它们也提供了独特的关注点，让人感觉它们好像是解决方法

回顾：核心Flask应用程序，允许在不同用户的基础上跨安装实现各种模板。定制和正确版本控制的最佳实践和权衡

我理解，通过允许使用者修改模板，这些模板在技术上违反了版本控制，因为它们不会被完全跟踪或忽略。我可能遗漏了一些明显的东西，如果这看起来毫无意义的话，我真诚的道歉

重要的是，主应用程序代码可以连续发布，消费者可以在可用时进行更新，但仍然保持自己的模板设计

在这个问题上，社区里有人有更可持续的方法吗？太好了！或者即使建议这样做？替代品也太好了！

非常感谢：）