Ergonomic, hermetic, user-friendly software build system for Python, Go, Java, Kotlin, Protobuf, Scala, Shell. Pants lets you fearlessly scale up your codebase!

Pants

I know you’ve invested significant cycles here, so want to be respectful of your time.

if you’d like, I could land #316 as-is and then apply an extraction of #399 on top of that before cutting a release.

(I’d ultimately hate to put you through another review cycle there, unless you’re fully up for it)

<@U054MQUPL> I don't have the time to dedicate to another review cycle, so definitely feel free to merge #316 and then get the additional changes you wanted from #399 on top of it before the release

<https://github.com/pantsbuild/pex/issues/461> :scream:

looks like it might’ve been caused by something as seemingly innocuous as enabling travis caching + potentially.. being on the wrong travis image?

:sparkles: manylinux support has arrived: <https://pypi.org/project/pex/1.4.0> :sparkles:

I feel like there needs to be a party for that one!

huh, q re: pex - what happens if you build a pex that includes python dependencies that use native libraries?

how do you make sure that the native libs (say, openssl) are installed? separte tooling?

theres no current paradigm for ensuring dynamically linked system libs for python apps that I’m aware of, beyond e.g. manylinux’s glibc checking

essentially those would just fail at runtime with ‘failed to find xxx.so’ etc

in our builds at Twitter tho, we lean very heavily on static linking at .whl construction time which optimizes for this sort of portability/isolation

and then we provide a standard Docker environment for those builds that only have our “base” libraries

This would be :100: as a built-in, to execute the build inside a given container, and even a layer to make it easy to run inside Kubernetes.

noting that the Docker image is for our wheelbuilder tool, not pants itself. so it’s more akin to a “pip install for the monorepo” that just puts prebuilt wheels in the right place for pants to consume. this helps obviate an entire host of at-build-time issues that can pop up when building sdists etc.

containerization is also not a solved problem for OSX, so we do our best and just build those locally on dev laptops

Agreed, the docker filesystem is sloooooooooooooow

longer term, we’re looking at remoting to solve the cross-platform build problem

but Docker + an emphasis on consumption of only bdists in the build has been a boon for our wheelbuilds/third party management

which effectively forces anyone who needs a lib that isn’t part of the OS core to bring that and statically link it

thats how we’ve been able to effectively deal with centos5/6/7 in prod

So are you using pants to build pex, or building them separately?

largely pants driven, but some `pex(1)` use for adhoc stuff

pex is now 1 half millennium old in PR years

<https://github.com/pantsbuild/pex/pull/507>

is it possible/reasonable to build pex binaries without the .pex extension?