You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I have searched the issues of this repo: Related to issue 5121, but while they want a more intelligent resolution, I wonder why version pinning of dependencies does not work.
If an exception occurs when executing a command, I executed it again in debug mode (-vvv option).
Description:
The pyproject I linked is a minimal version of our real pyorject.yaml (see below). It contains two major dependencies, that both rely on different versions of numpy depending on the python-version, platform, and chipset you are on:
install_requires =
numpy>=1.18.5; platform_machine!='aarch64' and platform_machine!='arm64' and python_version<'3.10'
numpy>=1.19.2; platform_machine=='aarch64' and python_version<'3.10'
numpy>=1.20.0; platform_machine=='arm64' and python_version<'3.10'
numpy>=1.21.0; python_version>='3.10'
It can quickly be seen, that no library has a more upper bound than numpy < 2.0, so using the newest version of numpy should just be fine. As the resolution system does not realize that on its own, I pinned my numpy to 1.21.2. However, this simply gets ignored, and the process is exactly the same, no matter if I specified this.
Why is this the case? I would suspect it is related to the different platform_machine and sys_platform markers. This is why I also tried to pin numpy for every possible combination of those, but this also did not help.
Is there any way to prevent poetry from resolving all those different strategies?
While this is more a small blemish in the posted example, it is a major issue in our real use case, as that one includes multiple packages living in a private package repository, which will interrupt the connection after a few minutes because of hitting the rate limit, which makes it practically impossible to use poetry at all.
The text was updated successfully, but these errors were encountered:
It can quickly be seen, that no library has a more upper bound than numpy < 2.0, so using the newest version of numpy should just be fine.
That's too short-sighted. Even if there is no upper bound, it is possible that a (transient) dependency of the latest numpy version conflicts with another dependency for a specific platform marker so that an older numpy version has to be used for that platform.
I pinned my numpy to 1.21.2. However, this simply gets ignored, and the process is exactly the same, no matter if I specified this.
That's just another constraint. It probably helps to avoid backtracking, so that the only version that is tried for all overrides is numpy 1.21.2 and if there is a conflict, no other versions are tried.
Is there any way to prevent poetry from resolving all those different strategies?
At the moment you can only restrict the python version (which you have already done in the given pyproject.toml). This avoids those overrides where the python version does not match. (I'm not sure how good this works in poetry 1.1.x so you may have to try 1.2 beta.)
If only specific platforms are relevant to you, you may be interested in #4956.
-vvv
option).Infos:
Description:
The pyproject I linked is a minimal version of our real pyorject.yaml (see below). It contains two major dependencies, that both rely on different versions of numpy depending on the python-version, platform, and chipset you are on:
pandas:
opencv-python:
When you resolve the project (
poetry lock -vvv
), poetry realizes that there are 16 different possible combinations and resolves all of them.Excerpt of the logs:
This will continue for 15 more strategies, so in the end, there will be these combinations:
It can quickly be seen, that no library has a more upper bound than
numpy < 2.0
, so using the newest version of numpy should just be fine. As the resolution system does not realize that on its own, I pinned my numpy to 1.21.2. However, this simply gets ignored, and the process is exactly the same, no matter if I specified this.Why is this the case? I would suspect it is related to the different
platform_machine
andsys_platform
markers. This is why I also tried to pin numpy for every possible combination of those, but this also did not help.Is there any way to prevent poetry from resolving all those different strategies?
While this is more a small blemish in the posted example, it is a major issue in our real use case, as that one includes multiple packages living in a private package repository, which will interrupt the connection after a few minutes because of hitting the rate limit, which makes it practically impossible to use poetry at all.
The text was updated successfully, but these errors were encountered: