Pip install editable poetry package fails on conflicting package version, although the exact same version is required

[galCohen88]

Description

Pip version resolver fails when installing Poetry package in editable mode if package is required both by TOML file & requirements.txt file:

INFO: pip is looking at multiple versions of first-library to determine which version is compatible with other requirements. This could take a while.
ERROR: Cannot install requirements.txt (line 1) and second-library 0.1.0 (from libs/second_library) because these package versions have conflicting dependencies.

The conflict is caused by:
    The user requested second-library 0.1.0 (from libs/second_library)
    first-library 0.1.0 depends on second-library 0.1.0 (from libs/second_library)

To fix this you could try to:
1. loosen the range of package versions you've specified
2. remove package versions to allow pip attempt to solve the dependency conflict

Expected behavior

No response

pip version

Pip 24.0

Python version

Python: 3.10.0

OS

MacOS

How to Reproduce

Create folder structure

requirements.txt
libs/first_library
libs/second_library

with requirements.txt content

-e ./libs/first_library
-e ./libs/second_library

first_library pyproject.toml dependencies

[tool.poetry.dependencies]
python = "^3.9"
second-library = {path = "../second_library", develop = true}

run

pip install -r requirements.txt

Output

The conflict is caused by:
    The user requested second-library 0.1.0 (from libs/second_library)
    first-library 0.1.0 depends on second-library 0.1.0 (from libs/second_library)

Code of Conduct

• [X] I agree to follow the PSF Code of Conduct.

[pfmoore]

This is (in effect) a duplicate of https://github.com/pypa/pip/issues/12502

In this particular case, the dependency

[tool.poetry.dependencies]
python = "^3.9"
second-library = {path = "../second_library", develop = true}

is specified using Poetry-specific syntax, so it's not obvious how this translates into actual standard dependency metadata, but I would expect it to generate a direct URL pointing to ../second_library - which is exactly the scenario in the issue I linked to above.

[ldlac]

is there any workaround to achieve this? I have the exact same problem.

this is a real use case in a monorepo context.