Мне интересно, можно ли управлять зависимостями расширения…
Вот ситуация, с которой я столкнулся.
Есть пакет 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.
