我有一个关于管理具有多个组件的 Git 项目的基本问题。我指的项目结构如下：
project-name
├── cli
├── api
├── webapp
├── docker-compose.yaml
├── README.md
├── LICENCE
我的目标是拥有一个优先考虑可维护性和代码重用性的结构。因此，核心功能都内置在 Python 的命令行界面 (cli) 中。我还在构建一个 rest api，目标是让它在后台使用 cli，而不是重写代码。
我的第一个问题是：这是一种好方法吗？我使用了许多基于 API 的 CLI（与我的方法相反），例如 AWS。我还使用了基于 CLI 的 API，例如 ffmpeg。因此，我不确定在我的情况下，按照我上面解释的方式是否有意义。
现在要链接 api 和 cli，我考虑了两种方法，但我不知道哪种最合适。
- 方法 A：使用项目内的相对路径直接从 api 调用 cli。但这是否意味着 cli 应该始终与 api 一起提供？
- 方法 B：将 CLI 单独构建为 Python 包并将其发布到存储库中，然后将其用作 API 中的要求。对我来说，这看起来“更干净”，但这意味着我不会立即看到我在 CLI 中所做的改进，因为我需要再次构建包并发布它。
我的第二个问题是：哪种方法是在 api 中引用 cli 的正确方法？（或者还有其他方法吗？）
提前致谢！
答案1
不，这里存在许多问题：
- API 不应使用 CLI。CLI 应该使用 API。
- 虽然你可以把 cli/app/webapp 放在一个 repo 中，但这被认为是糟糕的设计：它被称为“monorepo”。通常，您需要三个不同的存储库，其中 webapp 和 CLI 都调用 API。这也更好，因为一个 Dockerfile 几乎没有意义——您是在打包 cli 还是 webapp？我希望 cli 和 webapp 中都有一个 Dockerfile。
- 与 monorepo 相比，使用 micro repos 的优势主要在于工具。工具将为这些事情提供更好的支持。
- 使用 microrepo 会强制您的 cli 和 webapp 与 API 分开进行版本控制。这始终是可取的。例如，您可以同时使用两个不同版本的 API 开发两个版本的 web app 或 cli。从 cli 和 webapp 中提取 API 的工作方式与任何其他所需的外部依赖项一样。