0

I've specified the dependencies of a library using Poetry and ^ version constraints. The dependencies conflict if you just install the latest version of the dependencies, but they are resolvable and poetry install correctly resolves them. However, pip install from pyproject.toml does not correctly resolve them and creates a conflict.

Minimal example

directory structure:

poetry_poc/
poetry_poc/__init__.py
pyproject.toml

The __init__.py file is empty and the contents of pyproject.toml are:

[tool.poetry]
name = "poetry_poc"
version = "0.1.0"
description = "minimal example of issue"
authors = ["Your Name <you@example.com>"]

[tool.poetry.dependencies]
python = "^3.6"
requests = "^2.18.4"
snowflake-connector-python = "^2.2.9"

[tool.poetry.dev-dependencies]

[build-system]
requires = ["poetry>=0.12"]
build-backend = "poetry.masonry.api"

The constraint snowflake-connector-python = "^2.2.9" is only resolvable with version 2.2.9, so that gets installed. That library then requires requests<2.24.0, and my project specifies requests^2.18.4, so any version between 2.18.4 and 2.23.x would work just fine, but instead pip installs requests 2.24.0 and reports:

ERROR: snowflake-connector-python 2.2.9 has requirement requests<2.24.0, but you'll have requests 2.24.0 which is incompatible.

I've tried this on a brand new virtual environment with nothing but pip 20.1.1 and setuptools 39.0.1 installed, and I run pip install . --no-cache-dir so every dependency will be downloaded anew. My poetry version is 1.0.10.

Is this the expected behavior—that pip won't resolve these types of conflicts—or am I doing something wrong, or is this a bug?

daturkel
  • 1
  • 1
  • Give _pip_'s new dependency resolution a try: https://stackoverflow.com/a/62872812/11138259 – sinoroc Jul 24 '20 at 14:25
  • @sinoroc that works!! though i'm a little loathe to require my end-users install a prerelease version of pip and use the unstable feature flag. was i mistaken in assuming that pip would resolve this in its current version? – daturkel Jul 24 '20 at 14:36
  • Understandable. There is another thing to take into account: as far as I understood, _poetry_ uses non standard version specifiers (I don't know if "standard" is the right word here). In this case `^` is not part of [_PEP 440_](https://www.python.org/dev/peps/pep-0440/#version-specifiers) (which is more or less the standard specification). So that may (not sure, just a guess) have also introduced some extra complication. Maybe it would be interesting to show what was indeed written in the distribution's metadata. Maybe post the content of the `METADATA` file from the wheel. – sinoroc Jul 24 '20 at 14:42
  • Building the wheel with `poetry build` and inspecting it with the `wheel_inspect` lib, i see that it's correctly translated the `^` into requests `<3.0.0,>=2.18.4` and snowflake `<3.0.0,>=2.2.9`, so seemingly there is no issue there. (Additionally, switching to `>=` in pyproject gives the same result as in the original post.) – daturkel Jul 24 '20 at 15:48
  • Good. It was worth checking, to exclude _poetry_'s version specifier as potential cause. -- I would tell you to file an issue on _pip_'s bug tracker, but since it seems to be fixed in the (soon to be released?) new dependency solver I am not sure it would get attention. Might be worth filing the bug anyway, maybe you would get a different suggestion over there. -- Still I am bit surprised the current versions of _pip_ can't solve this, as it's not really a difficult one. -- I wouldn't worry too much about your end-users, it's out of your hands, just add a prominent note in your documentation. – sinoroc Jul 24 '20 at 16:10

0 Answers0