An env var that disables path recompilation triggers.

[ritchie46]

I would really love an environment var that disables all recompilation triggers of PyO3.

Currently I often patch pyo3 to prevent these recompilations.

I found it impossible to keep my path variable consistent in my flow, and given that pyo3 is used deep in our stack, this often triggers full 4/5min recompilations.

I know that the recompilations are done to prevent gnarly, bugs so I would document that env var (maybe not document at all) as "only use when you know what you are doing". Changes of paths, need to be followed up with a cargo clean.

[davidhewitt]

I'm definitely open to finding new ways to avoid recompilations, agreed this is a common source of pain. Is it definitely PATH changing which is causing issues for you? If you set PYO3_PYTHON, it should avoid reliance on PATH.

If it's related to rust-analyzer, maybe "rust-analyzer.cargo.targetDir": true, in VSCode settings can help?

[alex]

A thing we previously considered was using base python for PYO3_PYTHON. But this couldn't be done due to python packages relying on PYO3_PYTHON being the correct python in their build.rs.

A thing we could try is:

• Have maturin/setuptools-rust set both PYO3_PYTHON and PYO3_BASE_PYTHON
• Change pyo3 to, if PYO3_BASE_PYTHON is present, only set it in the rebuild-if-env-changed

This should reduce rebuilds significantly, I think?

[ritchie46]

PATH changing which is causing issues for you? If you set PYO3_PYTHON, it should avoid reliance on PATH.

Yes, I've tried everything in the docs, setting PYO3_PYTHON, always source the same environment, but I have a workflow where I need to link against Pyo3 in a script to setup some daemons. And it always retriggers a full recompilation. The patch I mentioned above, works like a charm for me, but I would also make it work in open source Polars, where we don't want to patch pyo3.

I believe it is triggered by PATH, but tbh, I gave up and just commented out all recompilation triggers 😅 .

[davidhewitt]

Have you got instructions to repro your workflow? I'd love to dig and try to understand if there's a general improvement without the nuclear option.

@alex I think we record the virtual env executable so that downstream build scripts can potentially reference it. But I like your idea and I wonder if we can split the API so that at least our use case only depends on the base.

[alex]

@davidhewitt yes, that's exactly right, I'm trying to have our cake and eat it too :-)

[ritchie46]

I can try if I can come up with a repro that is public, but what I do boils down to something like this. I have an .up.sh script to run daemons. The daemons need to be linked dynamically, so I modify library paths.

I also call from fish into bash, which I believe modifies the path variable pyo3 sees.

echo "PYO3_PYTHON = $PYO3_PYTHON"

PYTHON_LIBS=$(../.venv/bin/python -c "import site; print(site.getsitepackages()[0])")
echo "PYTHON_LIBS = $PYTHON_LIBS"

set -e

# compile two binaries (different dameons)
cargo build --bin mock_control_plane
cargo build --bin pc-cublet #--all-features

# We don't want to influence pyo3's builds, so mess with this after compilation!
PYTHON_SHARED_LIB=$(../.venv/bin/python -c "import sysconfig; print(sysconfig.get_config_var('LIBDIR'))")
export LD_LIBRARY_PATH="${LD_LIBRARY_PATH}:${PYTHON_SHARED_LIB}"

echo "LD_LIBRARY_PATH = $LD_LIBRARY_PATH"

# some other stuff
...

# start daemons

Then I have another terminal where I repetitively call cargo check, and my LSP (rust analyzer) also calls into cargo. The combination ./up.sh was terrible and unworkable.

In OSS Polars, I also often trigger a recompilation. In this case I haven't set PYO3_PYTHON and I believe it often happens when I switch branches or terminal tabs.

[ritchie46]

I don't know if this makes sense, but one thing that always triggers a full recompile (even if PYO3_PYTHON) is set is alternating maturin develop and maturin_build.