Skip to content

docs: Add a FAQ section about recompilation due to IDE #4183

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.

Sign up for GitHub

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

Open
wants to merge 1 commit into
base: main
Choose a base branch
from
Open

docs: Add a FAQ section about recompilation due to IDE #4183

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
11 changes: 11 additions & 0 deletions guide/src/faq.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -2,6 +2,17 @@

Sorry that you're having trouble using PyO3. If you can't find the answer to your problem in the list below, you can also reach out for help on [GitHub Discussions](https://github.com/PyO3/pyo3/discussions) and on [Discord](https://discord.gg/33kcChzH7f).

## `pyo3` is recompiled on every build

Unless a `PYO3_PYTHON` environment variable is set, PyO3 will use Python executable located in `$PATH` to build. However, you may have hidden processes building you crate, and then PyO3, with a different `PATH`; it's frequently the case with IDEs executing `cargo check` in background, as rust-analyser plugin does.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
Unless a `PYO3_PYTHON` environment variable is set, PyO3 will use Python executable located in `$PATH` to build. However, you may have hidden processes building you crate, and then PyO3, with a different `PATH`; it's frequently the case with IDEs executing `cargo check` in background, as rust-analyser plugin does.
Unless a `PYO3_PYTHON` environment variable is set, PyO3 will use the Python executable located in `$PATH` to build. However, you may have hidden processes building your crate, and then PyO3, with a different `PATH`; this is frequently the case with IDEs executing `cargo check` in background, as the rust-analyser plugin does.


A solution can be to set a fixed `PYO3_PYTHON` environment variable for each build. You can for example write a cargo [configuration file](https://doc.rust-lang.org/cargo/reference/config.html), e.g. `.cargo/config.toml`, with
```toml
[env]
PYO3_PYTHON = "venv/bin/python" # or any other Python path like "/usr/bin/python"
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Fixing the Python interpreter is one solution. Do we want to discuss the alternative to have rust-analyzer use a separate target directory, c.f. rust-lang/rust-analyzer#6007, as well?

IIRC, this is often recommended to avoid build directory lock contention and appears to be more general approach and does not have the downside of having to fix the interpreter? OTOH, fixing the interpreter might actually a good thing to avoid build and test errors and such coming from unexpected Python environments?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Fixing the Python interpreter is one solution. Do we want to discuss the alternative to have rust-analyzer use a separate target directory, c.f. rust-lang/rust-analyzer#6007, as well?

Indeed, I didn't considered this solution, and it may be indeed a better alternative.

OTOH, fixing the interpreter might actually a good thing to avoid build and test errors and such coming from unexpected Python environments?

Yes, but it's kind of unrelated to this question of the FAQ. If users encounter issues caused by unexpected Python interpreters, then I think it will be worth to add a dedicated question in the FAQ.

I will update the answer to mention target directory as the first solution.

```


## I'm experiencing deadlocks using PyO3 with lazy_static or once_cell!

`lazy_static` and `once_cell::sync` both use locks to ensure that initialization is performed only by a single thread. Because the Python GIL is an additional lock this can lead to deadlocks in the following way:
Expand Down
Loading