我想知道能不能控制扩展的依赖…
下面是我遇到的一个情况。
有一个 Q 包，它有一些依赖。它属于那种既定义接口，又提供同一个接口的多种实现的包。那些实现需要 HTTP 1 之类的依赖才能工作。
我现在正在开发 R 包。它基本完成了，我想为 Q 写一个实现 R 接口的扩展，就叫 QRExt。Q 不需要 HTTP，所以我不想把这些依赖加入 Q 的依赖列表。不过 QRExt 扩展本身确实需要依赖 HTTP 才能工作。目前没有问题，因为 Q 已经依赖 HTTP，所以加载 Q 就能使用 HTTP，QRExt 也能成功导入它。
问题在于，这种安排是偶然的，也可能改变。将来 Q 可能把 HTTP 依赖升级到 2。随后 QRExt 导入 HTTP 时期待的是(1)，拿到的却是 HTTP 2，于是就坏了。在“加载 Q 就能使用 HTTP”这个假设里，根本问题是没有任何东西明确要求这个假设一直成立。
我想听听该怎么处理的建议。
I'm wondering whether extension dependencies can be controlled…
Here's a situation I ran into.
There is a package Q with some dependencies. It belongs to that category of packages which define an interface and also supply several different implementations of that same interface. To operate, those implementations need dependencies such as HTTP 1.
I'm now developing package R. It's largely finished, and I want an extension to Q that implements R's interface, we'll name it QRExt. Q has no need for HTTP, so I don't want those dependencies added to Q's dependency list. The extension QRExt itself, however, does have a dependency on HTTP in order to work. Presently that works because Q already depends on HTTP, so loading Q means HTTP is available, letting QRExt import it successfully.
The trouble is that this arrangement is accidental and might change. Q could eventually move its HTTP dependency to 2. QRExt would subsequently import HTTP expecting (1), receive HTTP 2 instead, and break. With the assumption “loading Q makes HTTP available”, the underlying issue is that nothing expressly requires that assumption to keep holding.
Id be interested in ideas for handling this.
我觉得 weakdep 机制能提供你这里需要的大部分行为，不过 Q 迁移到 HTTP 2 时，仍有一些细节需要考虑。到时得更新 R 的 compat 条目，让 QRExt 能解析使用 HTTP 2 的新版 Q。我觉得这样挺合理，也很可能就是预期的结果？
I think the weakdep mechanism could provide most of the behavior you're looking for here, although there would still be a few caveats to consider when Q moves to HTTP 2. You'd then have to update R's compat entries so QRExt can resolve the newer Q version using HTTP 2. That seems reasonable to me, and likely the intended outcome?
如果 Q 不依赖 HTTP，就不要写你的
RQExt(我喜欢把被扩展的包放在前面)
而是可以写 RQHTTPExt
这样 R 就能在主项目文件中限制 HTTP 的 compat
If Q has no HTTP dependency, instead of writing your
RQExt (I like naming the extended package first)
You can write RQHTTPExt
R can then constrain HTTP's compat in its main project file
在开发环境里用 docker-compose up 启动所有服务时，我的几个容器会输出几百行又几百行内容。有没有方便的办法过滤这些输出，或者更好一些，让这些服务在 docker-compose up 运行时不要写到标准输出？
看来 D 能与 C 链接。我想用 D 编写 Python 扩展模块。我是不是漏掉了什么原因，导致这种方法根本无法运行？
python 可以这样写。 Python.withPackages (q: with q; [ fastapi ]) Micro 编辑器有类似的机制吗？ 能不能把 micro 编辑器的软件包和插件一起指定？:thinking: 那样会方便很多。
