pex
steering-council
pex | steering-council | |
---|---|---|
9 | 3 | |
2,454 | 153 | |
0.4% | 1.3% | |
8.9 | 6.9 | |
11 days ago | 2 months ago | |
Python | Makefile | |
Apache License 2.0 | - |
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
pex
-
Our Plan for Python 3.13
We get (very) close to cross-environment reproducible builds for Python with https://github.com/pantsbuild/pex (via Pants). For instance, we build Linux x86-64 artifacts that run on AWS Lambda, and can build them natively on ARM macOS.
This is not raw requirements.txt, but isn’t too far off: Pants/PEX can consume one to produce a hash-pinned lock file.
-
Is it possible pickle a function with its dependencies?
You should look into pex, or it’s parent build system pants. A PEX (Python EXecutable) file can package up all your code including dependencies and run on another machine of similar OS with just an available compatible interpreter.
- Pex: Python EXecutable
-
security risks in python libs
For well-supported libraries, pip-audit might do the trick. Where I've worked, we have used a central build system with library version enforcement. The build system produces a deployable archive, like PEX or similar. Rock-solid tests and sandbox validation environments provide good paths for version upgrades. Restricting libraries to a small set, making sure those repos remain actively developed, performing audits and centralizing builds has helped organizations I've worked in keep on top of potential security issues.
- My latest blogpost, python packaging has moved forward, but we're still missing a crucial part - what do you think?
- PyBake: Create single file standalone Python scripts with builtin frozen file system
- I am frustrated with packaging python, please educate me.
-
A function decorator that rewrites the bytecode to enable goto in Python
Don't know if I agree about the goto thing, but there are actually a number of options now for delivering varying degrees of self-contained Python executable.
When I evaluated the landscape a few years ago, I settled on PEX [1] as the solution that happened to fit my use-case the best— it uses a system-provided Python + stdlib, but otherwise brings everything (including compiled modules) with it in a self-extracting executable. Other popular options include pyinstaller and cx_freeze, which have different tradeoffs as far as size, speed, convenience, etc.
[1]: https://github.com/pantsbuild/pex
-
Mypyc: Compile type-annotated Python to C
Somewhat related, I had a devil of a time a little bit ago trying to ship a small Python app as a fully standalone environment runnable on "any Linux" (but for practical purposes, Ubuntu 16.04, 18.04, and 20.04). It turns out that if you don't want to use pip, and you don't want to build separate bundles for different OSes and Python versions, it can be surprisingly tricky to get this right. Just bundling the whole interpreter doesn't work either because it's tied to a particular stdlib which is then linked to specific versions of a bunch of system dependencies, so if you go that route, you basically end up taking an entire rootfs/container with you.
After evaluating a number of different solutions, I ended up being quite happy with pex: https://github.com/pantsbuild/pex
It basically bundles up the wheels for whatever your workspace needs, and then ships them in an archive with a bootstrap script that can recreate that environment on your target. But critically, it natively supports the idea of targeting multiple OS and Python versions, you just explicitly tell it which ones to include, eg:
--platform=manylinux2014_x86_64-cp-38-cp38 # 16.04
steering-council
-
Our Plan for Python 3.13
GVR called it a fork two weeks ago in his justification for not accepting it [1]. If that surprises you, the backstory is summarized pretty well in the article [2] and FAQ [3].
I'm really not trying to be secretive. We can debate whatever you want, but we have to at least acknowledge CPython's stated position.
[1] https://github.com/python/steering-council/issues/188#issuec...
[2] https://www.artima.com/weblogs/viewpost.jsp?thread=214235
[3] https://docs.python.org/3/faq/library.html#can-t-we-get-rid-...
-
Python PEP for Making the GIL Optional Doesn't Get Enough Support
Thanks for reviewing the PEP. The PEP was posted five months ago, and it has been 20 months since an end-to-end working implementation (that works with a large number of extensions) was discussed on python-dev. I appreciate everyone who has taken the time to review the PEP and offer comments and suggestions.
You wrote that the Steering Council's decision does not mean "no," but the steering council has not set a bar for acceptance, stated what evidence is actually needed, nor said when a final decision will be made. Given the expressed demand for PEP 703, it makes sense to me for the steering committee to develop a timeline for identifying the factors it may need to consider and for determining the steps that would be required for the change to happen smoothly.
Without these timelines and milestones in place, I would like to explain that the effect of the Steering Council's answer is a "no" in practice. I have been funded to work on this for the past few years with the milestone of submitting the PEP along with a comprehensive implementation to convince the Python community. Without specific concerns or a clear bar for acceptance, I (and my funding organization) will have to treat the current decision-in-limbo as a “no” and will be unable to pursue the PEP further.
Github Link: https://github.com/python/steering-council/issues/188#issuec...
-
PEP 681 – Data Class Transforms (accepted)
Hmm, likely because it was already submitted to the steering council since April and because the addition is relatively trivial (at runtime, it's almost a no-op).
What are some alternatives?
mypyc - Compile type annotated Python to fast C extensions
full-speed-python - Full Speed Python: a book for self-learners
setup.py - 📦 A Human's Ultimate Guide to setup.py.
opensergo-specification - Universal cloud-native microservice governance specification (微服务治理标准)
python-goto - A function decorator, that rewrites the bytecode, to enable goto in Python
nogil-3.12 - Multithreaded Python without the GIL (experimental rebase on 3.12)
pyBake - Create single file standalone Python scripts with builtin frozen file system
ideas
plusplus - Enables increment operators in Python using a bytecode hack
ideas5 - Batch 5 of Ideas for Computing
typed_python - An llvm-based framework for generating and calling into high-performance native code from Python.
mypyc-benchmark-results - Mypyc benchmark result data