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

• I agree to follow the PSF Code of Conduct.

[pfmoore]

This is (in effect) a duplicate of #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.

[williamhakim10]

Yeah, this is pretty annoying for monorepos. For now we've just been adding an old version of poetry-plugin-export which doesn't have the issue:

poetry self add poetry-plugin-export==1.7.1

[notatallshaw]

So I understand the workflow a bit, if you're using poetry to manage your environments, why are you using pip to install and not poetry?

It looks like poetry has set up a scenario that pip can't support because it doesn't know poetry specific information about the dependencies. In which case, there may be a workaround, but it's going to be related to how you set up the projects in poetry.

[williamhakim10]

In our specific situation, we use pip to install dependencies in places that are either annoying to use poetry (buildpacks) or simply require pip/requirements.txt full stop (Google Cloud Functions). When poetry exported other packages in the monorepo using a file path, pip was able to resolve the dependencies, but if it exports editable dependencies then pip is unable to resolve them.

[pfmoore]

That sounds like it's something that poetry should address in their export mechanism, then. As noted in #12502, pip doesn't support installing a local path twice, once in editable mode and once in non-editable mode. Poetry needs to take that into account somehow.