PyOxidizer / dynamically-embedding-the-python-interpreter / setting the libpython path at runtime #3454
Replies: 2 comments
-
Cc @indygreg who may be able to answer the question on PyOxidizer. I suspect that it's possible it just hasn't needed new feature work recently. Regarding the script / springboard, I suspect there is a lot of overlap with #3437 |
Beta Was this translation helpful? Give feedback.
-
The pyembed crate - while part of the PyOxidizer project umbrella - is a standalone crate with a higher-level API for managing embedded Python interpreters in a Rust program. See also the docs at https://gregoryszorc.com/docs/pyembed/main/. https://gregoryszorc.com/docs/pyoxidizer/main/pyoxidizer_rust_generic_embedding.html may also be worth a read. https://github.com/indygreg/PyOxidizer/tree/main/pyoxy is an example of a Rust application using pyembed to control an embedded Python interpreter. (The build machinery in GitHub Actions relies relies on PyOxidizer for producing the embedding artifacts.) |
Beta Was this translation helpful? Give feedback.
-
I have two related questions:
1.) In the pyo3 docs, here: https://pyo3.rs/main/building_and_distribution#dynamically-embedding-the-python-interpreter it says:
So my question is, is there a tried-and-true "springboard" solution that embeds the best practices for distributing a wrapper script? ie.
pyo3-build-config
already has a lot of logic for figuring out where the right libpython is, to use during build, so the wrapper script would ideally check if libpython is available in the path, resolve the path usingpyo3-build-config
if it isn't, and then set up the environment.Has anyone already written that script / springboard?
2.) It looks like PyOxidizer might be exactly what I am looking for. But it also looks like maintenance might have stopped. (no new commits in 9 months) Does anyone know the status of PyOxidizer.
Thanks for any insights.
Beta Was this translation helpful? Give feedback.
All reactions