Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support for full bundling of native dependencies / static linking #320

Closed
dsvensson opened this issue Nov 29, 2016 · 1 comment
Closed

Comments

@dsvensson
Copy link

Pex is cool when it comes to pure Python modules, and cases where you have control over the target environment. This is for example not the case for code to be deployed at AWS Lambda for example, or if you want to share your shiny PyQt-based app with some friends.

It would be very nice if Pex had support for gathering of dependencies, and setting up the appropriate library paths etc for the application to be able to execute fully from within the Pex file based on the OS/architecture it's executed under.

Without the support there will just be more and more projects like this:
https://github.com/moesy/AWS-Lambda-ML-Microservice-Skeleton
https://github.com/Miserlou/lambda-packages

It might be that this is a deeper problem with Python, and how Python modules are built, but to me as a user, it's what I expect to see when reading the description:

"...and makes the deployment of Python applications as simple as cp. pex files may even include multiple platform-specific Python distributions, meaning that a single pex file can be portable across Linux and OS X..."

@kwlzn
Copy link
Contributor

kwlzn commented Nov 29, 2016

It might be that this is a deeper problem with Python...

yes, this is a much deeper problem with python packaging that pex has no real control over. additionally, there is no 100% uniform way to ensure compatible static linking for all native dependencies at build time without additional configuration and components such as docker and pre-built docker images, which would vastly complicate the pex runtime.

the way most production shops solve this is by pre-building known-to-work bdists and handing those to pex at resolve time, rather than letting pex resolve against sdists which invoke setup.py to compile native code from source. this essentially pushes the work and control over static linking and compatibility up into the layer above pex, which I think is much more reliable and desirable. this approach also allows you to compose pex files in way that would otherwise require cross-compilation. for example, with pre-built bdists you can build a pex file with dependencies for both OSX and Linux from just your e.g. OSX laptop.

for the general case of "one binary dependency that executes on as many linux platforms as possible" tho, I think what you basically want here is manylinux. theoretically, if you target manylinux bdists (many of which get published directly to pypi), those should provide better runtime compatibility guarantees across Linux platforms.

the issue tracking manylinux support in pex is #281, so will close this one as a duplicate of that - so would subscribe to that issue for updates.

@kwlzn kwlzn closed this as completed Nov 29, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants