one quick question

where does the pex pickup the setuptools from?

does it pick up from the system wide installation?

IIRC it checks there 1st for compat, and if not resolves independently using the configured python repos / indexes or else falling back to pypi

Just a sec to confirm

my system installation shows the following

@User uploaded a file: Untitled

that I am running setuptools 33.1.1

Just confirming my guess from above - code here: https://github.com/pantsbuild/pex/blob/master/pex/bin/pex.py#L438-L492, pex 1st sees if the correct setuptools is in the interpreter sys.path and if not, resolves one and adds it to the interpreter setup via

Interpreter.with_extras

.

OK ... so the

Requirement

class actually comes from the pkg_resources module which should be provided by setuptools, and is fwict:

$ zipinfo -1 setuptools-33.1.1-py2.py3-none-any.whl | grep pkg_resources
pkg_resources/__init__.py
pkg_resources/_vendor/__init__.py
pkg_resources/_vendor/appdirs.py
pkg_resources/_vendor/pyparsing.py
pkg_resources/_vendor/six.py
pkg_resources/_vendor/packaging/__about__.py
pkg_resources/_vendor/packaging/__init__.py
pkg_resources/_vendor/packaging/_compat.py
pkg_resources/_vendor/packaging/_structures.py
pkg_resources/_vendor/packaging/markers.py
pkg_resources/_vendor/packaging/requirements.py
pkg_resources/_vendor/packaging/specifiers.py
pkg_resources/_vendor/packaging/utils.py
pkg_resources/_vendor/packaging/version.py
pkg_resources/extern/__init__.py

The

pkg_resources/__init__.py

there is very fancy and does the expected thing, exposing a

Requirement

class with a

specifier

attribute.

@most-wire-83210 try this:

$ ~/.pyenv/versions/2.7.13/bin/python
Python 2.7.13 (default, Feb 15 2017, 09:53:46) 
[GCC 6.3.1 20170109] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import pkg_resources
>>> pkg_resources.__file__
'/home/jsirois/.pyenv/versions/2.7.13/lib/python2.7/site-packages/pkg_resources/__init__.pyc'
>>> 'specifier' in dir(pkg_resources.Requirement.parse('foo==1.0.0'))
True
>>>

thanks @enough-analyst-54434 - here is the output

@User uploaded a file: Untitled

this is from the system installation

let me check if heron code base has its own pkg_resources

@most-wire-83210 I had a few developers here run into the "AttributeError: Requirement instance has no attribute 'specifier'" issue. Solved it by having them to install setuptools==30.0.0 (same as the version in our 3rdparty/requirements.txt)

ok cool

@acceptable-kitchen-41259 thanks for the workaround. That said, pex should ideally have perfect isolation and it would be great, if you have time @most-wire-83210 to get as much detail as possible into a github issue.

will do

thanks @acceptable-kitchen-41259 and @enough-analyst-54434 - working on it

hi. I’ve had some developers hit this bug at different times, running 1.3.0: https://github.com/sbt/zinc/issues/292

are there any plans to apply the zinc updates to 1.3.x or only 1.4.0?

I was thinking something along the lines of bazel’s execution environment somehow horking setuptools up - hence the ask for a pure-pex repro

also seemed like there was some degree of vendoring going on there wrt pex and potentially setuptools

based on file paths and whatnot

has pex always scanned the index even when using cached wheels on disk, or is that a new thing?

i’m seeing pex hitting our package index even though it’s pulling files out of the resolver cache

afaik, it’ll always hit all configured repos/indexes during a resolve to determine the set of available packages - then hit cache in lieu of fetching where possible.

possible there’s been a regression tho, so could backdate a pants/pex version and attempt to repro the behavior you’re seeing currently as a sanity check