Development of PyOxy strives to look like a normal Rust crate as much as
possible. This means that normal workflows such as
cargo build and
cargo test should work.
Please note that if you are working from the root of the PyOxidizer Git
repository, you may want to limit the package being operated on via e.g.
cargo build -p pyoxy or
cargo test -p pyoxy.
pyoxy crate depends on
pyembed, which depends on
insists on finding a runnable and linkable Python install in
can set the
PYO3_PYTHON environment variable to point at an explicit
Python interpreter rather than utilizing the default search logic.
pyoxy With Embedded Python¶
If you just
cargo build, it is likely that
pyo3 will pick up a
non-portable, dynamically linked
libpython. Furthermore, it will load
Python resources from the filesystem, from the path configured in
Such a configuration is not portable across machines!
To produce a portable, single file executable embedding
its resources, we need to perform a little extra work. This essentially entails
asking PyOxidizer to produce a static
libpython, a Python packed resources
file containing the standard library, and a PyO3 configuration file. Then, we
build with a reference to that PyO3 configuration file to link the appropriate
libpython and pick up the packed resources file.
cd pyoxy pyoxidizer build --release PYO3_CONFIG_FILE=$(pwd)/build/x86_64-unknown-linux-gnu/release/resources/pyo3-build-config-file.txt cargo build --release
On Linux, to ensure portability of the produced binary, you’ll need to link against a sufficiently old (and therefore widely available) glibc version. This often entails running the build/link in an older Linux distribution, such as Debian Jessie.
On macOS, you’ll probably want to define
MACOSX_DEPLOYMENT_TARGET to the
minimum version of macOS you want to target or else the produced binary won’t