request: mode where upper bounds on packages are not respected

[joelb123]

Let me begin by acknowledging that this problem is due to assumptions by upstream package managers, not a fault of your package. I will take up the issue with poetry upstream, although the huge number of open issues (644) there does not make me feel it will get taken care of quickly. The reason I ask you to do a workaround is that I suspect this is a common problem for any package that uses poetry. I don't use flit, so I don't know if it does the same things.

Poetry has a pretty strong implicit assumption that the package is going to be installed into a virtualenv, so it puts a maximum version on every dependency with a maximum value that seems to be the next major release in semantic versioning. This has the effect of making the package nearly uninstallable if one is working with an environment more up-to-date than what the developer was using in their development virtualenv.

Take Poetry itself: the lockfile calls for the dependency 'keyring>=20.0.1,<21.0.0', but portage has only keyring 21.2.1 available. It turns out that poetry works fine for me with keyring:21 and it's the assumption that the next major-numbered release breaks the build that is incorrect.

So, whomever wants to write an ebuild for poetry (like me) has to write a patch that whacks out all the upper-bound version numbers. I ask that you add an ebuild variable to disrespect upper-bound limits in lockfiles to eliminate the need for such patches.

[mgorny]

Err, but pp2sp doesn't even support dependencies — I mean, it's designed specifically to be used by external package managers, so it ignores Python dep specs entirely.

[joelb123]

I feel that I explained this badly, though it's possible that I simply didn't understand. I have raised this issue with poetry upstream, , which just came alive again after months of nobody paying attention.

The problem arises in ebuilds where the dependency upper limits generated by poetry (on the basis of assumptions about semantic versioning rather than definite info from the pyproject.toml) happen to be exceeded by newer versions in the Gentoo tree. For example, from an draft ebuild I wrote for poetry-1.1.4, which was written after dev-python/keyring went to 22.0 in-tree, while the setup.py that pp2sp generates 'keyring>=21.2.0,<22.0.0', resulting in a build-time failure. I solved it in needing the following patch:

poetry-1.1.4-no-pinned-deps.patch.txt

Again, this is really upstream's problem, but I'm guessing this problem will show up more as more projects move to poetry.

[mgorny]

As said above, pp2sp doesn't even look at the dependencies, so it doesn't enforce them at all.