poetry export --format requirements.txt … export a commit hash of an installed repository instead of the initial used tag reference.

[guillaumededrie]

Poetry is used to build a package that will be installed in a Docker image:

# Build
$ poetry build --format wheel
$ poetry export --format requirements.txt --output constraints.txt --without-hashes

# Export the .whl and constraints.txt file (multi-stage build)

# Install
$ pip install --no-cache-dir ./$APP_NAME*.whl --constraint constraints.txt

As of today, it was working well. But we've added a new package using this (as an example) poetry add git+https://github.com/me/new-package#1.6.0 (new-package = {git = "https://github.com/me/new-package", rev = "1.6.0"} is present in the [tool.poetry.dependencies] of the pyproject.toml) and when we tried to install the generated wheel by Poetry using an exported requirements.txt, we ended up with this error:

The conflict is caused by:
    my-app 1.0.0 depends on new-package 1.6.0 (from git+https://github.com/me/new-package@1.6.0)
    The user requested (constraint) new-package
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
ERROR: ResolutionImpossible: for help visit https://pip.pypa.io/en/latest/topics/dependency-resolution/#dealing-with-dependency-conflicts

If we take a look at the constraints.txt file, we can see that line: new-package @ git+https://github.com/me/new-package@c3e22d63f50256f588bd1438eedcd761a1507a43 ; python_version >= "3.11" and python_version < "4.0", which doesn't match the initial git+https://github.com/me/new-package@1.6.0.

Workarounds

If we replace this line by new-package @ git+https://github.com/me/new-package@1.6.0 the problem disappear.

[dimbleby]

you have exported requirements.txt and are trying to use that as constraints. if you wanted constraints you should have exported with the constraints.txt format

(though I don't know whether that will make a difference here)

but probably you can just treat it as requirements.txt all along pip install --no-deps -r requirements.txt

[guillaumededrie]

@dimbleby thanks for the --format constraints.txt tip, didn't see the option.
Unfortunently, the results is the same (== the commit hash is used instead of the tag version).

What you are suggesting is installing first the dependencies and not combining it with the package installation?

[dimbleby]

if everything is working then requirements.txt contains all dependencies, there is no need to ask pip to rediscover them (and risk that it disagrees)

fwiw I find it hard to call the exported requirements.txt wrong. Locking to an exact sha is the most reliable way of, well, locking.

I doubt that you will get much traction but imo it would be logical to call this a pip bug for failing to recognise that the tag and the sha represent the same thing.

[rusmux]

This is also a problem for me. My requirements.txt does not contain all dependencies, I cannot use the --no-deps option. I agree that locking the exact hashes of packages is the most reliable way to pin versions, however, it does break pip installation. Is it possible to add some simple flag to the export requirements without hashes?

[dimbleby]

My requirements.txt does not contain all dependencies, I cannot use the --no-deps option

Yes it does - that's what poetry export does - and yes you can.