I maintain a package
alpha, which depends on
beta also depends on
gamma. All packages primarily support Python3.8+, but retain backwards compatibility to Python2.7 for legacy users.
beta have both been upgraded to use a new API in
While the new release of
gamma, the current
setup.py file defines an incompatibility with the new branch of
gamma under Python 2.7-3.5 – and will raise a VersionConflict because it wishes to install an earlier version of
gamma. This earlier version is not an option, because of API changes.
All three packages are compatible with the earlier environments and each other, and all packages pass all tests under the earlier environments. The incompatibility is entirely dictated by the “requires” directive in
Short of forking
beta to adjust
setup.py until a PR would hopefully be accepted, is there any way to force the requirement restrictions to be ignored? This is causing a nightmare for my CI tests.
I’ve never had to accomplish this before, and I haven’t been able to find any good documentation for this scenario online.
Is there not a good reason that
beta is incompatible with
gamma for Python <3.6? Could you then say that the version of
gamma's new API is for Python 3.6+ only?
A reason? Sure. A good reason? IMHO, no. When it comes to 2.7, the version conflict is purely because of the requirements file - the code is fully compatible. All tests pass with nearly full coverage. The restriction happened while 3.5 was being deprecated and a regression in certain versions of Gamma was being isolated out.
Beta, the library with the version conflict, provides glue between
Delta - both of which are larger, well-known Python projects with large install bases of legacy deployments and are still helping 2.7 users migrate. The newer Gamma version was designed, in part, to backport forthcoming breaking API changes – so that legacy users can finish Python3 migrations while also updating their usage of that library in a single pass.
Having contributed to all projects involved in this, I am fairly certain this was an unintended oversight.
That being said, my goal is not to restrict usage but enable it.
Is there any particular reason for using “artificial” names for these projects? You mention that at least some of the packages involved are well known, so it’s not clear why you’re obfuscating the names. It’s making it very hard to follow what’s going on.
The answer is basically no, there’s no way to override the declared intent of the package author (short of using
--no-deps when installing). There may be a more nuanced answer, but frankly I’m finding it too hard to keep track of the alpha/beta/gamma/delta names to be sure
No, it was just to make this a more generic question.
- beta - zope.sqlalchemy
- gamma - sqlalchemy
- delta - zope/zope.transaction
The maintainers of zope.sqlalchemy already have a fix in the works. The 2.7 restriction was an unrealized artifact of a 3.5 deprecation.
That would actually solve my problems!