and if you can’t find a way to do pure python platforms in pants, would be good to file a bug with what you’ve tried so far - that should be totally possible.

@rough-minister-58256 Yeah 'none'/None didn't work at all. Empty list "works" but it just has the same behavior as "current" as far as I can tell -- although I'm not convinced there isn't a cached wheel somewhere I need to blow away. If I find some free time I might explore the code to better understand what's going on. It's kind of a messed up situation -- these third party modules are designed to have native code "speedups" but fallback to pure python in the case where those speedups fail to compile for some reason (usually due to a missing system dep, you know, like gcc!) The only way to know that it won't work is to try it and watch it fail and fall back to the pure python module. Instead of doing that, I don't want it to ever try, because if it succeeds, it will build a binary on the wrong platform. But, unless the setup.py can be asked to not try, or unless the python can somehow be hobbled such that it has no ability to ever build extension modules, I'm not sure how to solve the problem. (The very specific problem I'm trying to solve is building linux docker containers that hold .pex files. If you build the pex on a mac you can't copy it into a linux docker container.)

Perhaps linux-gcc cross compiling on a mac is in order? 🤔 😄

Kidding.

hi, any idea if/when the manylinux pr will be merged in for a release? currently hacking around it with the custom wheel repo

But would like to avoid doing that

@gifted-beard-62952 has left the channel

@rough-minister-58256 is there anything left to do on https://github.com/pantsbuild/pex/pull/316 ? has been out for weeks and solves a huge pain point for me. apologies if I'm being pushy

I can take another look, but afaik that PR was deadlocked on an API design issue that the author wasn’t willing to budge on.

@rough-minister-58256 from what I can tell he implemented your suggestion?

in the world of pex and the v1.3.0 python rewrite, is the

python-repos

->`repos` pants config still the right way to expose a directory of wheels to pants?

I ask because Pants seems unable to resolve a wheel that I've configured via that method

(a custom wheel versus one that would be found on pypi)

yeah

what's the interaction with

python-setup

->

platforms

?

I had that config as

platforms: ['macosx-10.9-x86_64', 'manylinux1_x86_64']

and pex would not resolve a

py2-none-any

dep

(it threw its unsatisifiable dep exception)

I set platforms to

[]

and suddenly it is able to resolve that dep and gets much further in the pants command I was running

(which was just

./pants test.pytest

of a test target)

if I set to platforms to

['py2-none-any', 'macosx-10.9-x86_64', 'manylinux1_x86_64']

, then pants or pex hangs (probably an infinite loop?) when it reaches the resolution point

I see the default for python-setup-platforms is

current

setting platforms to

['current', 'macosx-10.9-x86_64', 'manylinux1_x86_64']

gets me the same result as the empty case (which is to say it is able to resolve the dep that wasn't resolving)

magic

afaik,

manylinux1_x86_64

isn’t a valid platform name - maybe it would ‘just work’, but I’ve never tried it. pex currently doesn’t support manylinux in the traditional sense.

I don't believe the

manylinux1_x86_64

platform was the issue though

my problem was resolved via putting

current

in the list

which seems to get special treatment

(and is the default value for that pants config)

another pex question: why does pex scrub site-packages directories from the sys.path?