I believe 1.3.0 is still affected by a wheel handling issue that causes certain deps (like tensorflow) to not be importable, but master or one of the recent dev releases should contain a fix.

./pants --version

gives 1.3.0.dev14

would try with e.g. 1.4.0.dev13

...12 probably. 13 didn't go out.

doesn’t look like 12 went out on pypi either - latest is pantsbuild.pants 1.4.0.dev11

was jar_dependency_utils removed since 1.3.0dev14? getting errors about that now

may have been but you should’ve seen deprecation warnings for it in the prior major release if so

Says yes:

$ git log -Sjar_dependency_utils
commit b7cd335efae0290caf4cafff4eac77aebfc9344a
Author: Benjy Weinberger <benjyw@gmail.com>
Date:   Sat Mar 18 23:05:06 2017 +0200

    Fix missing and circular deps. (#4345)
    
    The main fixes are:
    
    - Move jar_dependency*.py and exclude.py out of the JVM backend
      and into core (specifically, the already existing pants.java.jar
      package, which seems like a logical place).
    
    - Move a utility function from classpath_util.py to classpath_products.py
      (and change the corresponding tests appropriately).
    
    - A few random missing deps noticed along the way.
    
    These changes, while intrusive, are necessary to fix the dep cycles
    mentioned in the issue below.  Fortunately they are also quite logical:
    In particular, since JarDependency is not a target, it makes sense for
    it to live outside pants.backend.jvm.targets.  And moving it into core
    paves the way for using JVM-based tools in non-JVM backends without
    having to depend on the entire JVM backend (e.g., python ANTLR codegen
    needs to run a JVM, but doesn't care about JVM source code in the repo).
    
    Addresses <https://github.com/pantsbuild/pants/issues/4138>.

$ git diff --stat b7cd335efae0290caf4cafff4eac77aebfc9344a^! | grep _utils src/python/pants/backend/jvm/ivy_utils.py | 8 +- .../jvm => java/jar}/jar_dependency_utils.py | 0 .../pants_test/backend/jvm/tasks/test_ivy_utils.py | 6 +- .../backend/jvm/test_jar_dependency_utils.py | 2 +-

So, still there, but moved

Was that public API?

Yeah

Well, some classes in jar_dependency_utils.py were anyway.

d’oh

@average-vr-56795 it’d be handy to have a readme entry for running rust tests in src/rust/engine/README.md

Good call 🙂 Adding to my PR

hi folks, trying to include nbconvert in a pex, and it keeps pulling in functools32, which throws since it shouldn't run on py3

is there any way to tell pants to not download this dependency?

A quick test with pex directly does not repro:

pex --python=python3 nbconvert -o nbconvert

then

zipinfo nbconvert | grep functools32

comes up empty.

What version of pants and are you specifying interpreter constraints to force pants to pick python 3 and resolve for python 3?

pants 1.3.0, interpreter_constraints: CPython>=3.5

the offending package that pulls in functools32 is jsonschema, which puts that in the extras_require

@best-intern-74122 uploaded a file: pants.ini

Can you sanity check the interpreter_constraint with

./pants options --scope=python-setup --name=interpreter-constraints

?

python-setup.interpreter_constraints = ['CPython>=3.5'] (from CONFIG)

appears to be a known pex bug here: https://github.com/pantsbuild/pants/issues/4490

OK, but not a pex bug. As noted by kwlzn and re-confirmed by my experiment above, pex handles this - pants using pex under the covers does not

hmm, fair enough

still, an annoying pants bug then

no way to control who uses functools32, and the workaround is less than satisfactory: create a dummy functools32 package that doesn't throw on py3

does it improve at all if you specify interpreter constraints on the target level?