i was just asking if that was the ticket you were referring to. currently running the suite locally, and i don't see anything that looks like a resolve failure yet

No, these issues: https://github.com/pantsbuild/pants/issues/4723 https://github.com/pantsbuild/pants/issues/5406

ah, yep.

Some pex reviews in prep for release are going up this afternoon. If anyone wants to review - thank you in advance.

And with a not-insignificant delay, 1.4.8 is released: * https://github.com/pantsbuild/pex/releases/tag/v1.4.8 * https://pypi.org/project/pex/1.4.8/ I'll tee up a pants upgrade PR presently.

thank you john!

@enough-analyst-54434: my understanding of why jupyter is used there is that it is a pretty high-profile ML tool. twitter uses it a bit, and i have heard from another ML engineer (cough em) that they use it

Yes, but jupyter itself is fake, out tests could be using the module directly.

To whit: https://pypi.org/project/jupyter/#history

Its just an empty package depending on all the real ones without constraints

At least for pex - which is testing env-markers specifically, jupyter has none, its jupyter-console, etc that do

In fact - I dug enough that this convinces me to switch to jupyter_console for the pex tests. I can look at doing the same in pants depending on what pants is testing for.

ok

thank you: that would be appreciated.

i didn't actually get a chance to begin looking at https://travis-ci.org/pantsbuild/pants/jobs/437552336

OK. FWIW, the correct test in pex: https://github.com/pantsbuild/pex/pull/578

confirmed that master is currently seeing this on shard 3

Yeah - https://github.com/pantsbuild/pants/pull/6600

thanks john.

going to merge a few things atop that.

A few pex releases coming tonight / tomorrow: + 1.4.9 will have a bugfix over 1.4.8: https://github.com/pantsbuild/pex/issues/583 + 1.5.0 will introduce new functionality with a semi-public API break (Pants uses the API at any rate): https://github.com/pantsbuild/pex/issues/585 And https://github.com/pantsbuild/pex/issues/584 tracks pinning down a semver policy / API for pex, which has probably been wanting.

The 1.4.9 hotfix is released: + https://github.com/pantsbuild/pex/releases/tag/v1.4.9 + https://pypi.org/project/pex/1.4.9/

And the 1.5.0 release is out hot on its heels: + https://github.com/pantsbuild/pex/releases/tag/v1.5.0 + https://pypi.org/project/pex/1.5.0/

One more. 1.5.1 with the fix to bring full environment marker support: + https://github.com/pantsbuild/pex/releases/tag/v1.5.1 + https://pypi.org/project/pex/1.5.1/

nice!

hitting a strange pex issue deep in the depths of one of our ML tools, wondering if anyone’s encountered the same before:

pex: PEX is not zip safe, exploding to /Users/kwilson/.pex/code/3abed9b0e11a4a550f42f3de7c47d7987a659cd0
pex: Adding to the head of sys.path: /Users/kwilson/.pex/code/3abed9b0e11a4a550f42f3de7c47d7987a659cd0
pex: Adding to the head of encodings.__path__: /Users/kwilson/.pex/code/3abed9b0e11a4a550f42f3de7c47d7987a659cd0/encodings
pex: Adding to the head of collections.__path__: /Users/kwilson/.pex/code/3abed9b0e11a4a550f42f3de7c47d7987a659cd0/collections
pex: Adding to the head of importlib.__path__: /Users/kwilson/.pex/code/3abed9b0e11a4a550f42f3de7c47d7987a659cd0/importlib
pex: Adding to the head of _pex.__path__: /Users/kwilson/.pex/code/3abed9b0e11a4a550f42f3de7c47d7987a659cd0/_pex
pex: Adding to the head of ctypes.__path__: /Users/kwilson/.pex/code/3abed9b0e11a4a550f42f3de7c47d7987a659cd0/ctypes
pex: Adding to the head of ctypes.macholib.__path__: /Users/kwilson/.pex/code/3abed9b0e11a4a550f42f3de7c47d7987a659cd0/ctypes/macholib
pex: Adding to the head of urllib.__path__: /Users/kwilson/.pex/code/3abed9b0e11a4a550f42f3de7c47d7987a659cd0/urllib
pex: Adding to the head of email.__path__: /Users/kwilson/.pex/code/3abed9b0e11a4a550f42f3de7c47d7987a659cd0/email
pex: Adding to the head of http.__path__: /Users/kwilson/.pex/code/3abed9b0e11a4a550f42f3de7c47d7987a659cd0/http
pex: Adding to the head of pkg_resources.__path__: /Users/kwilson/.pex/code/3abed9b0e11a4a550f42f3de7c47d7987a659cd0/pkg_resources
pex: Adding to the head of xml.__path__: /Users/kwilson/.pex/code/3abed9b0e11a4a550f42f3de7c47d7987a659cd0/xml
pex: Adding to the head of xml.parsers.__path__: /Users/kwilson/.pex/code/3abed9b0e11a4a550f42f3de7c47d7987a659cd0/xml/parsers
pex: Adding to the head of pkg_resources.extern.__path__: /Users/kwilson/.pex/code/3abed9b0e11a4a550f42f3de7c47d7987a659cd0/pkg_resources/extern
pex: Adding to the head of pkg_resources._vendor.__path__: /Users/kwilson/.pex/code/3abed9b0e11a4a550f42f3de7c47d7987a659cd0/pkg_resources/_vendor
pex: Adding to the head of pkg_resources._vendor.packaging.__path__: /Users/kwilson/.pex/code/3abed9b0e11a4a550f42f3de7c47d7987a659cd0/pkg_resources/extern/packaging
pex: Adding to the head of distutils.__path__: /Users/kwilson/.pex/code/3abed9b0e11a4a550f42f3de7c47d7987a659cd0/distutils
pex: Adding to the head of logging.__path__: /Users/kwilson/.pex/code/3abed9b0e11a4a550f42f3de7c47d7987a659cd0/logging
pex: Adding to the head of json.__path__: /Users/kwilson/.pex/code/3abed9b0e11a4a550f42f3de7c47d7987a659cd0/json
pex: Adding to the head of mpl_toolkits.__path__: /Users/kwilson/.pex/code/3abed9b0e11a4a550f42f3de7c47d7987a659cd0/mpl_toolkits
Traceback (most recent call last):
  File ".bootstrap/_pex/pex.py", line 364, in execute
  File ".bootstrap/_pex/pex.py", line 90, in _activate
  File ".bootstrap/_pex/environment.py", line 147, in activate
  File ".bootstrap/_pex/environment.py", line 198, in _activate
  File ".bootstrap/_pex/environment.py", line 64, in update_module_paths
AttributeError: '_NamespacePath' object has no attribute 'insert'

seems to non-deterministically barf on handling of mathplotlib’s

mpl_toolkits

namespace package + the

google

ones

this screamed

setuptools

version to me, but after aligning that to

setuptools==33.1.1

across all involved pex’ and interpreters (and fully rebuilding all involved pex files due to the vendored sealing pex does) it still repros - trying to work backward to a minimal repro for issue filing now.

thinking some topical relief in the form of ducktype handling of

__path__

in

update_module_paths

might help round a sharp edge there tho