When trying to do a pants package of a binary that...
# general
h
When trying to do a pants package of a binary that doesn’t specify an explicit interpreter_constraint but relies upon pants choosing the min version in the global interpreter_constraints it seems that pants is choosing to build the requirement set for all interpreters found on my system. With ps I see that pip is running for 2.7.17, 3.6.9, 3.8.6 and 3.9.0 which are all versions i have installed with pyenv. But this package should only choose 2.7.17 since one of its deps is py2 only. I caught this because pants was throwing an exception building the wheel for the py2 only package. pants repl and pants test correctly constrain to the 2.7.17 interpreter I’m on 2.2.0 I can workaround this by constraining explicitly in the target.
The multiple processes all appear to be performing the pip download command
e
By "one of its deps is py2 only" you mean there is a dep that declares interpreter constraints that limit to py2 only?
h
the dep is GreenletProfiler==0.1 and it fails to build a wheel for py3. So the download is attempting to build from an sdist with py3
e
Sure - I'm trying to clarify the "py2 only" phrase. Is the code that is py2 only decalred as such to pants with interpreter constraints for the owning target?
h
it is not explicitly declared no
e
In other words I'm trying to quickly rule out the case where the python code is in fact py2 only - which you know - but pants does not.
Aha
Well, that's it then.
h
my understanding of the global interpreter constraints is that it chooses the min version
and pants repl and pants test both work
e
Only for running. IOW only when the code needs to be executed.
👍 1
When you build a distibutable like a PEX file, it builds for all matching interpreters.
So, the pex_binary in question needs the fix you gave - it needs to say it only works with python 2.
h
interesting
e
In other words, you're getting luck on any goal that executes the code.
👍 1
Lucky in the sense that the algorithm happens to pick min.
h
yes we have been relying upon that for quite some time
and it does seem inconsistent that package behaves differently than repl and test
e
Agreed.
h
we will adjust tho, thanks for the info
e
Really, repl and test should be failing here in some sense, since a goal at some level is to have the repl'd tested' binary be the same as the shipped one ... and Pants, without a py2 only cnstraint on the pex_binary - expects the shipped PEX should be able to run on py2 and py3.
...erm, repl and run should be failing ... since those should be using the shipped binary in spirit.
Or maybe just run.
h
yah we’ve been relying upon the choosing of min to be able to have py2/3 compat python_libraries, i.e. we don’t specify an interpreter constraint on 2/3 python_libs, they are then depended upon by a python_binary that sets an explicit constraint and then we have separate py_test targets with explicit constraints. This choice was made so we didn’t have to update every build file and duplicate a py3 variant for every lib
however, relying upon the min meant that for py2 binaries or test targets we didn’t specify the explicit constraints
we can do that though