I maintain a package alpha, which depends on beta and gamma; beta also depends on gamma. All packages primarily support Python3.8+, but retain backwards compatibility to Python2.7 for legacy users.
alpha and beta have both been upgraded to use a new API in gamma.
While the new release of beta supports 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 setup.py.
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 alpha supporting 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 Gamma and 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
