Is poetry the right tool for me in light of dependency resolution with respect to Python version?

[marius311]

I've got the following pyproject.toml:

[tool.poetry.dependencies]
python = "^3.8"
numpy = "^1.21"

which (I had thought) means my project needs at least Python 3.8 and at least numpy 1.21 (up to the semver upper bounds).

So a user with Python 3.8 would get numpy 1.24.4 (the last 3.8-compatible version), since that combo meets those requirements, and a user with Python 3.9 could get numpy 1.25 and above, which also meets them.

But that doesn't seem to be happening. Even on a system with Python 3.9, poetry lock resolves to numpy 1.24.4. So it seems poetry always resolves to versions that will work with all (ie the lowest) allowed Python.

Am I right in this? Is poetry fundamentally not the right tool if instead I want the behavior stated above of users on 3.8/3.9 getting different numpy versions? I understand I could use markers but then its like I'm manually doing dependency resolutions and gets complicated quickly with lots of packages. Thanks for any info.

[dimbleby]

The behaviour of poetry is as you describe, but it is possible that this is not particularly relevant.

are your users installing your package from source, using poetry install? if not, then the behaviour of poetry lock is not relevant to them.

the poetry lockfile provides something like a proof that requirements are consistent and that users will be able to install them. But it says very little about what they will actually install.

That is because only the requirements, and not the solution, make it into wheels eg as published to pypi.

So what users get at install time will depend on what tool they use to do the installation (poetry? pip? other?), what other requirements they have in their project, what environmental constraints they themselves provide, etc

[marius311]

Thanks yea I should have specified. This is for a project where a small team is all cloning a repo and running poetry install. I suppose I was imagining only the pyproject.toml is in the repo which I thought might allow the behavior above, although even that doesn't.

I suppose what I was imagining was like a per-Python-version lock file, so everything is pinned but newer versions can use newer stuff, but maybe thats outside the scope of Poetry (and admitedly doing that is a bit wierd in some ways).

[clintonroy]

It's possible to specify different versions of deps based on the python version, but it's a bit manual:

https://python-poetry.org/docs/dependency-specification/#multiple-constraints-dependencies

[marius311]

Answered in the replies, or at least pushed me to further think about what I really need. Thanks!