Hi all. I’ve got an issue with Pants claiming it cannot find artifacts that pipenv finds just fine. I’ve got a simplified example here: https://github.com/nikwotton/Broken-Pants-Demo - when I run

pipenv install

it works fine but when I run

./pants generate-lockfiles

it claims numpy cannot be found

So what are your interpreter constraints?

Is there documentation somewhere on what Pants automatically takes from a pipfile and what it doesn’t? It seems arbitrary to me…

Pants is trying to create a lock for >=3.7 by default and probably failing trying to get a 3.11 or 3.12 wheel

*Pipfile.lock

Sure - I think this was a recent addition by a new contributor. SO maybe pile on and chip in a fix.

Fair enough

Yeah, all the language is about requirements (dependencies): https://github.com/pantsbuild/pants/blob/main/src/python/pants/backend/python/macros/pipenv_requirements.py

hmm, I added the line you suggested and I’m getting the same error actually

Just a sec, let me repro with your repo. Thanks again for making that.

actually, I pushed another commit you may want to pull - if I remove the python requirement from the pipfile it still fails

So our docs apparently lie? Agreed global ICs don't work, this does:

$ git diff
diff --git a/pants.toml b/pants.toml
index f343697..893d76f 100644
--- a/pants.toml
+++ b/pants.toml
@@ -8,6 +8,7 @@ backend_packages = [
 # This will become the default in Pants 2.15.
 tailor_pex_binary_targets = false
 enable_resolves = true
+#interpreter_constraints = "==3.7.*"

 [anonymous-telemetry]
 enabled = true
@@ -15,3 +16,6 @@ repo_id = "ED3CCABC-6067-47DD-A959-353BC3F02836"

 [python.resolves]
 My_Resolve = "3rdparty/python/my_resolve.lock"
+
+[python.resolves_to_interpreter_constraints]
+My_Resolve = ["==3.7.*"]

It works with numpy….I can still reproduce the issue with other dependencies though 😞 Pushed an example of it breaking with pandas - same issue,

pipenv install

works but

./pants generate-lockfiles

fails

So the 1st check is does the failing thing have a more specific Python requirement than you? We've had folks get stomped on the package wanting, say,

>=3.7.1

and them saying, like you,

==3.7.*

Sorry, was in a meeting

So the 1st check is does the failing thing have a more specific Python requirement than you? We’ve had folks get stomped on the package wanting, say,

>=3.7.1

and them saying, like you,

==3.7.*

TBH it’s not fully clear to me how to tell what the failing thing’s python requirements are - I don’t see one in the Pipfile.lock for example. Apologies if there’s an obvious answer, I’m still a little new to Python in general 😬 Ah, I see it’s on pypi.org

can you confirm this is the issue with this last one?

I can confirm that setting a more specific version does fix the issue, if that’s what you’re asking. It’s unclear whether the version matters though or just that it be specific - In docker 3.7.5 works and on my machine directly 3.7.15 works. Those just happen to be versions I have installed, I haven’t tried others yet

It wants

>=3.7.1

Pex will keep you honest.

Ahhhh, that makes sense I think. To parrot back what you’re saying, Pex is stricter in version requirements than Pipenv - it’s not that pants should be succeeding but that pipenv should’ve been failing because 3.7.0 does not work. Either failing, or marking in its lockfile the >=3.7.1 requirement, which it didn’t do. Given all of this information, it seems using Pex through Pants will be a boon to my codebase because it forces more exact versioning, which I am definitely in favor of

Ok, yeah. It sounds like you understand what's going on here. That's what I was hoping for. You can make your own judgements with that knowledge.

Big thanks for the help!