Hi all, I have an issue when I try to package a pex_binary. I get the following error:

ProcessExecutionFailure: Process 'Building src.python.herzensgut.accounts/serve.pex with 12 requirements: bcrypt==3.2.0, databases[postgresql]==0.5.3, email-validator==1.1.3, fastapi-health==0.4.0, fastapi-jwt==0.1.7, fastapi-mail==1.0.2, fastapi==0.70.0, passlib==1.7.4, pyjwt==2.0.1, python-dotenv==0.19.2, python-multipart==0.0.5, uvicorn==0.16.0' failed with exit code 1.
stdout:

stderr:
ERROR: Could not find a version that satisfies the requirement fastapi-jwt==0.1.7
ERROR: No matching distribution found for fastapi-jwt==0.1.7

The strange thing is, that running the

pex_binary

is working. This is my BUILD file:

python_requirement(
    requirements=[
        "bcrypt==3.2.0",
        "fastapi==0.70.0",
        "fastapi-health==0.4.0",
        "fastapi-jwt==0.1.7",
        "fastapi-mail==1.0.2",
        "email-validator==1.1.3",
        "passlib==1.7.4",
        "pyjwt==2.0.1",
        "python-dotenv==0.19.2",
        "python-multipart==0.0.5",
        "uvicorn==0.16.0",
    ]
)

resources(
    name="queries",
    sources=[
        "**/*.sql",
    ],
)

resources(
    name="templates",
    sources=[
        "**/*.html",
    ],
)

python_sources(
    name="lib",
    sources=[
        "**/*.py",
    ],
    dependencies=[
        ":queries",
        ":templates",
        "src/python/herzensgut/shared:lib",
    ],
)

python_distribution(
    name="dist",
    dependencies=[
        ":lib",
    ],
    wheel=True,
    sdist=True,
    provides=setup_py(
        version="0.0.1",
        name="herzensgut.accounts",
        description="",
    ),
)

pex_binary(
    name="serve",
    restartable=True,
    entry_point="app/api/server.py",
)

Do you have an idea what the problem is? Thanks!

Is it possible that one of your other requirements is pulling it in transitively? Generally speaking, locking direct dependencies like that is likely to lead to an infeasible set of requirements for a package.

Thanks for your quick response! Hmm, no there is no other requirement which depends on the package. But, is there a better approach to organize direct dependencies?

There was a bit of discussion here

Hmm, why are you using a single

python_requirement

target for all the requirements? It means that they will always be depended on all together, and Pants won't be able to treat them as separate things. The more idiomatic way to do this would be to put those in a

requirements.txt

(or some other name) and point to it in a

python_requirements()

target .

possibly related, or not, but:

you mean

./pants run

is working but

./pants package

is not? That is strange

I got this today on 2.9.0. Tried on 2.11.0rc0 and got a totally different error (but at least consistent between

run

and

package

) working on a repro, hopefully by tomorrow..

Thanks for your reply Andreas. So, yep,

./pants run

is working but

./pants package

isn’t. This is my interpreter constraints:

interpreter_constraints = [
    "CPython>=3.9.7",
]

So I dont think this is the cause.

Hmm, and what happens if you switch to

python_requirements()

and a

requirements.txt

file?

I’ve tried using the requirements.txt resulting in the same error. The databases[postgresql] dependency comes from the

shared:lib:

python_requirements()

python_sources(
    name="lib",
    sources=["**/*.py"],
)

python_distribution(
    name="dist",
    dependencies=[":lib"],
    wheel=True,
    sdist=True,
    provides=setup_py(
        version="0.0.1",
        name="herzensgut.shared",
        description="",
    ),
)

Could the wheel / sdist setting being a problem? fastapi-jwt only provides a wheel file, as far I can see: https://pypi.org/simple/fastapi-jwt/

Yeah, it's a universal wheel so that shouldn't be an issue.

Yeah sure, will do this tomorrow, as it’s already 7 PM here in Germany 🙂 Until then, thank you very much for your help!

You're welcome! Ping us here with that repo and we'll keep digging 🙂 Have a good night!

After a last try I was able to solve the issue. 🎉 You have mentioned the interpreter constraints. Using the follwing interpreter_constraints in my pants.toml the package command succeeded.

interpreter_constraints = [
    ">=3.9.7",
    "<3.10",
]

When I remove the “<3.10” it breaks. But I have absolutely no idea why this could break the process …

Great! Glad that worked