I’m currently refactoring a package I maintain into several sub-packages, inspired by the way argon2 was structured:
pypqc
pypqc-cffi-bindings-libre
pypqc-cffi-bindings-falcon
pypqc-cffi-bindings-hqc
pypqc-cffi-bindings-kyber
At some point in the next few years, I hope to secure an OSI-approved license for Kyber. If I succeed, I plan on merging the -kyber
package into the -libre
package and deprecating the separate package.
But I’m trying to decide which of these is the correct approach:
Option 1: deprecate the old package, and conflict with it
- Publish a new, Kyber-included version of the
-libre
package, and declare it explicitly as conflicting with the-kyber
package, since it provides the same physical files; - Deprecate the
-kyber
package; - Publish a metadata-only post-release of
pypqc
that makes the[kyber]
extra depend on at least the new, Kyber-included version of the-libre
package.
This seems like the cleanest, best, and obviously correct option — except that I can’t figure out how to do this, and I’m worried it’s just not supported by Pip.
Option 2: lockstep hand-off
- Publish a new, Kyber-included version of the
-libre
package, which depends on the next major version of the-kyber
package; - Simultaneously publish a new major version of the
-kyber
package which provides no files, and depends on the new, Kyber-included version of the-libre
package; - Publish a metadata-only post-release of
pypqc
that makes the[kyber]
extra depend on at least the new, Kyber-included version of the-libre
package.
This seems like it would work, but feels over-engineered and seems to lock me into keeping a “package carcass” positively pulled in as a dependency forever. Not great.
Option 3: laissez-faire hand-off
(Basically just the same as option 2 except without pulling in a dud package forever)
- Publish a version of the
-kyber
package that provides no files, emits a deprecation warning on installation, and depends on the next major version of the-libre
package; - Publish a new, Kyber-included major version of the
-libre
package;- if anyone ends up with a file conflict, declare it a skill issue on their part for doing piecemeal updates and not using latest stable release of all applicable packages
- Publish a metadata-only post-release of
pypqc
that makes the[kyber]
extra depend on at least the new, Kyber-included version of the-libre
package.
Option 4: go back in time and establish different premises
Right now, I have not committed to this new packaging split.
If the way I’m setting this up now is going to fundamentally cause my future self strife if/when it comes time to fold these splinters into the OSI-approved-licensed baseline, I’d like to know what other options there are.