확장의 의존성을 제어할 수 있는지 궁금합니다…
제가 겪은 상황은 이렇습니다.
어떤 의존성들이 있는 Q라는 패키지가 있습니다. 인터페이스를 정의하고 그 인터페이스의 여러 구현도 제공하는 종류의 패키지입니다. 그 구현들이 동작하려면 HTTP 1 같은 의존성이 필요합니다.
저는 지금 R 패키지를 개발하고 있습니다. 거의 완성했고, R의 인터페이스를 구현하는 Q용 확장을 쓰려고 하는데 QRExt라고 하겠습니다. Q는 HTTP가 필요 없으니 Q의 의존성 목록에 그것들을 더하고 싶지는 않습니다. 하지만 QRExt 확장 자체는 동작하려면 HTTP에 의존합니다. 현재는 Q가 이미 HTTP에 의존하므로 Q를 로드하면 HTTP를 사용할 수 있어 QRExt에서 임포트가 잘 됩니다.
문제는 이 구성이 우연이고 바뀔 수도 있다는 겁니다. 언젠가 Q가 HTTP 의존성을 2로 올릴 수 있습니다. 그러면 QRExt는 (1)을 기대하고 HTTP를 임포트했는데 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.
