pdm export error when building service images

[disco-king]

Describe the Bug

When I try to run docker compose up after setting up the environment I get the following error when it gets to building books and reviews images:

 => [federation-demo-reviews builder 5/6] COPY pyproject.toml pdm.lock /app/
 => ERROR [federation-demo-reviews builder 6/6] RUN pdm export -o requirements.txt
 => [federation-demo-books builder 5/6] COPY pyproject.toml pdm.lock /app/
 => ERROR [federation-demo-books builder 6/6] RUN pdm export -o requirements.txt
------
 > [federation-demo-reviews builder 6/6] RUN pdm export -o requirements.txt:
#0 1.309 [PdmUsageError]: Can't export a lock file without environment markers, please re-generate the lock file with `inherit_metadata` strategy.
------
------
 > [federation-demo-books builder 6/6] RUN pdm export -o requirements.txt:
#0 1.172 [PdmUsageError]: Can't export a lock file without environment markers, please re-generate the lock file with `inherit_metadata` strategy.
------

The same goes for trying to generate the requirements file outside of a container, in my system (demo uses python:3.10-slim, which is pretty close to my environment):

$> pdm --version
PDM, version 2.19.2
$> pdm export -o requirements.txt
[PdmUsageError]: Can't export a lock file without environment markers, please re-generate the lock file with `inherit_metadata` strategy.

System Information

• Operating system: Linux debian 6.1.0-26-amd64

Additional Context

For anyone having the same issue and in need of a quick workaround: I was able to build the images by writing requirements files manually and just copying them into the images in the dockerfiles. For both GraphQL services they might look something like this:

strawberry-graphql==0.131.1
uvicorn==0.18.2
starlette==0.20.4

Obviously this is not an adequate solution, but works if you just need to quickly set up the demo.

[patrick91]

@disco-king did you figure out a solution? otherwise I can try to find some time to update this repo 😊

[disco-king]

@patrick91 no, I didn't try to, just went with the hack. It would be helpful if you updated the repo.

[ncoghlan]

I came across this issue report while investigating a similar exception in a different project.

It appears to be due to a change in pdm's default dependency resolution strategy, so my eventual resolution was:

• delete the failing pdm.lock
• run pdm config --local strategy.inherit_metadata True (so conditional dependencies in the lock file inherit the marker flags of the entries that depend on them)
• regenerate pdm.lock with that locking strategy flag set