Stuck on an issue?

Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.

And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.

enviroment markers ignored when multiple version options coexist with legacy source

See original GitHub issue

Poetry version: 1.2.1
Python version: 3.10.6
OS version and name: macOS 10.15.7
pyproject.toml: https://gist.github.com/seansfkelley/fe46b800efa747f9917f9979a4757874

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.

Possibly related: #3561, #6215, #5506,

Issue

When I attempt poetry install on macOS, Poetry tries to install torch=1.11.0+cpu, which does not have appropriate native builds:

poetry install   
Installing dependencies from lock file

Package operations: 1 install, 0 updates, 0 removals

  • Installing torch (1.11.0+cpu): Failed

  RuntimeError

  Unable to find installation candidates for torch (1.11.0+cpu)

  at ~/Library/Application Support/pypoetry/venv/lib/python3.10/site-packages/poetry/installation/chooser.py:103 in choose_for
       99│ 
      100│             links.append(link)
      101│ 
      102│         if not links:
    → 103│             raise RuntimeError(f"Unable to find installation candidates for {package}")
      104│ 
      105│         # Get the best link
      106│         chosen = max(links, key=lambda link: self._sort_key(package, link))
      107│

If I remove the non-Darwin option and leave only this one:

{ version = "1.11.0", markers = "sys_platform == 'darwin'", source = "pypi" }

Poetry installs it without issue.

If I instead replace the non-PyPI option with some other, distinct option and remove the pytorch legacy source:

{ version = "1.12.0", markers = "sys_platform != 'darwin'", source = "pypi" }

(note the version and source are different from the original non-Darwin option)

I can then freely change around the markers on both versions and reinstall and it will always select the intended version according to the rules.

The behavior of apparently ignoring markers only seems to happen when the source is not PyPI.

The non-Darwin source is used in a Docker build, and, if I remove the multiple options and simply set torch = "1.11.0+cpu", I am able to correctly install torch==1.11.0+cpu in my Docker build using this source configuration.