Arbitrary Equality Requirements

[bentheiii]

• [X] I have searched the issues of this repo and believe that this is not a duplicate.
• [X] I have searched the FAQ and general documentation and believe that my question is not already covered.

Feature Request

Hi, I think poetry should support arbitrary equality requirements as described in PEP 440. Current behavior is problematic in case of the following usage:

[tool.poetry.dependencies]
xgboost= [
    {version = "0.81+upstream", markers = "sys_platform == 'linux'", source="***"},
    {version = "0.81", markers = "sys_platform != 'linux'", source="***"},
]

Results in only the 0.81+upstream version ever being installed (as though installed with pip install xgboost==0.81, which too installs 0.81+upstream if available)

I propose to make the following requirement legal

[tool.poetry.dependencies]
xgboost= [
    {version = "0.81+upstream", markers = "sys_platform == 'linux'", source="***"},
    {version = "===0.81", markers = "sys_platform != 'linux'", source="***"},
]

Which will install 0.81+upstream on linux systems and 0.81 on non-linux systems (install as though with pip install xgboost===0.81)

[radoering]

Is source the same for both constraints? If source is not the same and (maybe additionally) 0.81+upstream does not exist in the other source, your first example should already work as desired.

[bentheiii]

Hi @radoering, in this case the source was the same, and changing them to be different was possible and fixed my issue, Thanks. However, I still think the feature has merit, since changing the sources is not always possible.

[simonrouse9461]

Any update on this? I'm facing the same issue when installing torch-scatter. This is the command I used:

poetry source add pyg-cpu https://data.pyg.org/whl/torch-2.0.0+cpu.html
poetry add torch-scatter@==2.1.1 --source pyg-cpu

There are two versions for torch-scatter in the source link, 2.1.1 and 2.1.1+pt20cpu, but poetry cannot distinguish them even if I explicitly specify @==2.1.1.

[maxhgerlach]

This issue makes it really hard to add a CPU-only dependency to PyTorch 2.1.0 RC which would work on both Linux and macOS.

I can't just have

# ...
[[tool.poetry.source]]
name = "Torch CPU test builds"
url = "https://download.pytorch.org/whl/test/cpu"
priority = "explicit"

# ...
[tool.poetry.dependencies]
torch = {version = "^2.1.0", source="Torch CPU test builds" }

Because for Intel Linux and Windows the package source offers 2.1.0+cpu, but for macOS only 2.1.0. Poetry will always prefer 2.1.0+cpu here, then fail on macOS. It would be great if I could just specify an analog of torch===2.1.0 in Poetry for one of the systems.

I guess currently the only workaround would be to upload the macOS packages to a separate, locally managed, source?

---

Edit: Workaround for my use case -- specify direct URLs for the Mac variations:

torch = [
    { version = "2.1.0+cpu", markers = "sys_platform=='linux'", source="Torch CPU test builds" },
    { url = "https://download.pytorch.org/whl/test/cpu/torch-2.1.0-cp39-none-macosx_11_0_arm64.whl", markers = "platform_system == 'Darwin' and platform_machine == 'arm64'" },
    { url = "https://download.pytorch.org/whl/test/cpu/torch-2.1.0-cp39-none-macosx_10_9_x86_64.whl", markers = "platform_system == 'Darwin' and platform_machine == 'x86_64'"}
]

[dimbleby]

while it is superficially appealing to use arbitrary equality to resolve this sort of cpu-only local-version stuff - it would not be consistent with the intention of the spec:

Arbitrary equality is added as an “escape clause” to handle the case where someone needs to install a project which uses a non compliant version.

ie it is not meant to be for packages that are using perfectly good PEP440 versions - but which are overloading those versions with more meaning than they were ever capable of carrying.

I would caution against trying to work around mis-use of local versions by layering on top of that mis-use of arbitrary equality.

if there really is a use case here that torch etc cannot resolve within the existing python version specifications: engage with the python packaging authority and get the specs improved.

[analog-cbarber]

Wish poetry would stop resisting implementation of python standards. Even if use of the arbitrary equality clause is for corner cases, it is still there for a reason. And it is not like implementing this poetry would be difficult. Please stop giving us reasons to not adopt poetry.

[radoering]

Wish poetry would stop resisting implementation of python standards.

I do not think we decided on not implementing it. After all, this feature request is still open. It is just too low priority for anyone to invest more time on the implementation. I gave it a (halfhearted) try myself some time ago, but abandoned it because it was not as simple as I had expected first.

[analog-cbarber]

I see. I would consider trying to work on it but only if I thought there was a very good chance that it would be accepted.