Updates interpreter path parsing to handle Jenkins

[daveFNbuck]

When building a pex on Jenkins inside an auto-generated virtualenv, I keep ending up with interpreter names like CPython-2.7.3.tmp.ba3a2c39daab46ef978ba07fe335079d. If we simply split on dots to get version number, we'll end up with an invalid version number. To avoid this, we now just take the first 3 items when splitting on a dot. This allows pex building for me on Jenkins.

[kwlzn]

I think the larger question here is why the interpreter discovery mechanism is finding what it deems valid interpreters that look like 'CPython-2.7.3.tmp.ba3a2c39daab46ef978ba07fe335079d' or where they're coming from to begin with.

any clues from your analysis? here's what these should normally look like in cache:

$ find ~/.pex/interpreters
/Users/kw/.pex/interpreters
/Users/kw/.pex/interpreters/CPython-2.7.10
/Users/kw/.pex/interpreters/CPython-2.7.10/wheel
/Users/kw/.pex/interpreters/CPython-2.7.10/wheel-0.24.0-py2.7.egg
/Users/kw/.pex/interpreters/CPython-2.7.6
/Users/kw/.pex/interpreters/CPython-2.7.6/wheel
/Users/kw/.pex/interpreters/CPython-2.7.6/wheel-0.24.0-py2.7.egg

but in your interpreter cache, you'd probably find the *.tmp.* variety which is likely where this code is choking.

related:

• "too many values to unpack" when parsing interpreter versions #140
• "ValueError: too many values to unpack" when parsing interpreter versions pantsbuild/pants#2038

[daveFNbuck]

It seems that this happened because of the failure fixed in #191. I can't
replicate it on my laptop, so it's probably something weird with how my CI
generates temporary workspaces. With #191 applied I don't have this issue,
so I'm ok to close.

On Fri, Jan 1, 2016 at 11:57 AM, Kris Wilson notifications@github.com
wrote:

In pex/interpreter.py
#192 (comment):

@@ -95,7 +95,7 @@ def from_id_string(cls, id_string):
@classmethod
def from_path(cls, dirname):
interp, version = dirname.split('-')

• major, minor, patch = version.split('.')
• major, minor, patch = version.split('.')[:3]

I think the larger question here is why the interpreter discovery
mechanism is finding what it deems valid interpreters that look like
'CPython-2.7.3.tmp.ba3a2c39daab46ef978ba07fe335079d' or where they're
coming from to begin with.

any clues from your analysis? here's what these should normally look like
in cache:

$ find ~/.pex/interpreters
/Users/kw/.pex/interpreters
/Users/kw/.pex/interpreters/CPython-2.7.10
/Users/kw/.pex/interpreters/CPython-2.7.10/wheel
/Users/kw/.pex/interpreters/CPython-2.7.10/wheel-0.24.0-py2.7.egg
/Users/kw/.pex/interpreters/CPython-2.7.6
/Users/kw/.pex/interpreters/CPython-2.7.6/wheel
/Users/kw/.pex/interpreters/CPython-2.7.6/wheel-0.24.0-py2.7.egg

but in your interpreter cache, you'd probably find the .tmp. variety
which is likely where this code is choking.

related:

• "too many values to unpack" when parsing interpreter versions #140 "too many values to unpack" when parsing interpreter versions #140
• "ValueError: too many values to unpack" when parsing interpreter versions pantsbuild/pants#2038
  "ValueError: too many values to unpack" when parsing interpreter versions pantsbuild/pants#2038

—
Reply to this email directly or view it on GitHub
https://github.com/pantsbuild/pex/pull/192/files#r48679975.