and that totally makes sense, i was thinking of it as the interpreter is a "managed" runtime outside of pants but not within pants -- hence your comment on "except for pants devs" above. definitely get the bit about build/runtime

so this error i'm seeing doesn't repro using

./build-support/bin/ci.sh

on master, but it does if i just run the test target, and it's the same error message that i'm seeing in the osx shard on my PR (not master) (which is running

ci.sh

obviously), that's enough for me to pass out for today. thanks!

@rough-minister-58256 what’s a good way to run pex from pex’s source?

got it. thanks!

@rough-minister-58256 e.g.

pex x y z -c alpha

, do the

x y z

here without the argument always mean 3rdparty dep?

2nd Q: when doing

./pex_binary pex -c pex -o pex.pex

, how does it figure out

pex.bin.pex:main

is entry point?

Python question: if entry point is

x.y:main

. Does it mean it has to be `x/y.py`’s

def main

, or could it also mean

x/y/main.py

?

the former

ah great. glad there’s no ambiguity 🙂

the latter (module execution) is a thing, but would be

x.y.main

iirc

ok, but that’s not how pex works, correct?

or is it possible to pass a module to pex?

you can totally pass modules to execute, just without the

:

got it. so

:

means a method exactly

thanks!

yep

is there a quick way to run checkstyle locally in pex repo?

ah figured out by running

TOXENV=style ./scripts/ci.sh

, but maybe there’s a better way to run locally.

(this isn't necessarily a pex question, but it is about python packaging in pants -- let me know if i should move to #general) i'm trying to adding an option that evaluates

setup.py

files for pants

python_dist()

targets in a context that gives them access to pants code (in this case, so that the setup.py can import a pants module which extends distutils/setuptools classes. it is entirely possible to write the distutils/setuptools extensions as a completely separate pypi module, as they don't currently need to rely on other parts of pants, and could then just be accessed using

setup_requires

in the

python_dist()

target (and this is actually pretty reasonable). however, it seems like it should be possible to somehow expose the running pants environment to the setup.py invocation we do in

BuildLocalPythonDistributions

and/or

SetupPyRunner

, so the setup.py can just do:

from setuptools import find_packages
from distutils.core import Extension
from pants.some.module import setup

setup(
  # ...,
  ext_modules=[Extension(...)],
  packages=find_packages(),

I assume this would be done either by creating a pex with the pants requirement, or by adding something to

PYTHONPATH

in the executing environment for the setup.py. this probably isn't that hard when using pants in any other repo besides the pants repo because we can expect a pex with all the relevant pants code to be available, since that is how pants is released, but i can't figure out how to expose the python code from the running pants to a setup.py invocation (i may be trying to go about this all wrong). there's a very little more context in https://github.com/pantsbuild/pants/issues/5661

and these distutils/setuptools extensions are almost definitely not going to be usable just for pants, so it might actually be most reasonable to release that as a separate package on pypi -- if that's not a horrible idea, would it need to be part of the pants org, or can/should it be a separate thirdparty module? i would obviously release it apache 2 in that case

Is it possible that a pex built in mac won't be able to run in linux? One of my team members is reporting this. The specific dependency that it fails on is pandas and pyarrow.

Totally possible. More details about the build (did you specify a multi-platform pex?) and runtime environments are needed though.

ah, how can you specify a multi-platform pex?

i see that pex has the

--platform

arg, but trying to find how to make that happen with pants

found the target argument

platforms

! thanks for suggesting that 🙂

I'm getting a build error when I add the platform tag on OSX

my BUILD file looks like:

python_binary(
    name='foo-entrypoint',
    dependencies=[
        ':foo-base',
            ],
    platforms=['current', 'linux-x86_64'],
    source='entrypoint.py',
)