-
Notifications
You must be signed in to change notification settings - Fork 2.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Pedantic IncompatibleConstraintsError
with scipy
1.11.2 on Debian
#8409
Comments
poetry builds cross-platform solutions - even for build environments - and has detected and reported a possible combination of markers with conflicting requirements. looks like the scipy build requirements are just bugged, these lines should include something about possibly "python installed from source" is contributing to making this hard for yourself, you likely ought to be able to use one of the scipy binary distributions and I can only guess that there's something about your build that prevents this. |
Looks like scipy agrees with your assessment! Poetry is technically right, but it's also being pedantic. I imagine there's a good reason for building architecture-agnostic solutions, but I'm just trying to manage packages for deployment on the architectures I'm using, which is x86_64. Is there any possibility of dismissing this kind of error from Poetry, perhaps by specifying in |
IncompatibleConstraintsError
with scipy
1.11.2 on DebianIncompatibleConstraintsError
with scipy
1.11.2 on Debian
Actually, I think it's not necessary to solve the build requirements cross-platform because we only build on demand during installation for the current platform (after creating the lockfile for the project). We just did it because it was simpler to implement. At the moment locking is done implicitly here: poetry/src/poetry/installation/chef.py Lines 70 to 80 in 5986df0
... and we have no parameters to say "lock only for the current platform". I think in case of the build requirements it would make sense since the lockfile is only temporary so there is no danger that someone picks up the lockfile and uses it on another platform. But as always: the issue had to become important enough for someone who's capable to solve it. |
I have a similar problem with scipy. the error message in the log is entirely correct ==> but it seems to point to the code not resolving the backwards range that scipy has posted on pypi. Most post their compatibility range starting low(>=3.8) and ending high(< 3.12). I suspect poetry reads it wrong. here's part of the log: " SolveFailure The current project's Python requirement (>=3.10) is not compatible with some of the required packages Python requirement: Because pkg depends on scipy (1.10.1) which requires Python <3.12,>=3.8, version solving failed. at ~/.local/pipx/venvs/poetry/lib/python3.10/site-packages/poetry/mixology/version_solver.py:416 in _resolve_conflict" |
Poetry states to specify the python requirement via the python or markers properties. Suggesting, for scipy, to set its python property to >=3.10,<3.13. It then provides links to how to do this using either "Python restricted dependencies" or "environment markers". The very next entry in their documentation is for Multiple constraints dependencies, with which you can add scipy as a * dependency for >=3.13 if you so please. There really isn't any other alternative since the version that will support 3.13 is unknown. This is likely what you want. [tool.poetry.dependencies]
python = ">=3.10"
scipy = {version = "^1.10.1", python = ">=3.10,<3.12"} Or, if you want to be fancy... [tool.poetry.dependencies]
python = "^3.10"
scipy = [
{version = "^1.10.1", python = ">=3.10,<3.12"},
{version = "^1.11.3", python = "3.12"},
{version = "*", python = ">=3.13"},
] |
@BeRT2me did you continue your test? Did you try to install? I'd already done both for python and scipy as you've outlined in the toml file. I'm talking about a bug in Poetry code-- and plainly stated in poetry's own error log -- If you read it slowly and closely -- this is the error: " The current project's Python requirement (>=3.10) is not compatible with some of the required packages Python requirement: Because pkg depends on scipy (1.10.1) which requires Python <3.12,>=3.8, version solving failed. Notice how scipy's Python requirement is NOT the usual order(start with the lower limit, end with the upper limit) and poetry fails to recognize that difference in it's message? Poetry looks at the first limit as the "lower" limit, so it fails to add scipy, even after I've specifed everything correctly in the toml for both python and scipy Numpy gives me the same problem, on "poetry add numpy" but it will install it as a requirement for another package.. And numpy has the same backwards python-required-range on pypi.org. |
@dadudadn what you are reporting is both (i) not what this issue describes - this is specifically about build requirements - and (ii) not a bug. Please read the FAQ and stop hijacking this issue. |
@dadudadn both of my configs work perfectly fine. You say |
Poetry version: 1.6.1
Python version: 3.10.13 (installed from source)
OS version and name: Debian 12.1 (bookworm), x86_64
pyproject.toml: https://raw.githubusercontent.com/isosphere/VolAdjGIPDashboard/master/pyproject.toml
I am on the latest stable Poetry version, installed using a recommended method.
I have searched the issues of this repo and believe that this is not a duplicate.
I have consulted the FAQ and blog for any relevant entries or release notes.
If an exception occurs when executing a command, I executed it again in debug mode (
-vvv
option) and have included the output below.Issue
pip 23.2.1
This is an x86_64 system on Debian Linux - the above restrictions are irrelevant, or at least the meaning of this error is misleading.
numpy 1.25.2 is installed in the virtual env.
I've reinstalled poetry, and also the virtual env, to no avail. Not sure how to move forward. I've tried specifying different scipy versions, but I just get different variations on the above. I don't understand how constraints that don't apply to my system are preventing installation.
Any advice appreciated!
Possibly related to #7257.
The text was updated successfully, but these errors were encountered: