Skip to content
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.

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

Fix runtime conflict between embedded and system Python #37

Merged
merged 5 commits into from
Oct 2, 2023

Conversation

dean0x7d
Copy link
Member

@dean0x7d dean0x7d commented Sep 25, 2023

This PR primarily fixes an issue where the embedded python(3) executable could still pick up some paths from the system Python which resulted in obscure, hard-to-debug issues. It's important to keep in mind that there are two ways to run the embedded Python:

  1. From inside an application via the shared library and Python C API.
  2. Directly via the python(3) executable in the embedded package.

Case 1 is how we mainly use it and it wasn't really an issue because we already enabled isolated mode at initialization time using the Python C API.

Case 2 is something we do at build time to run some utilities (e.g. convert Jupytext to . ipynb files) or at runtime (launch Jupyter notebooks in a standalone process). When calling the python(3) exe directly, isolated mode can be set either via the -I command line parameter or by adding a ._pth file next to the executable. It's easy to forget or not know to always add -I so it's best for the embedded package itself to have a ._pth file to avoid issues. See the docstrings for more details.

This PR also fixes #36 and a few other smaller bugs. See the individual commit messages. Thanks to @hrishikeshkelkar for finding both the bug and what causes it.

`embedded_python-core` already provides the include dirs and non-core
inherits it. There's no reason for non-core to add them again.
We didn't catch this on CI since we only test lowest and highest
supported versions. I don't think I'd change this CI setup just
for this, but maybe reconsider in the future if such a case happens
again.
Copy link
Member

@hellozee hellozee left a comment

Choose a reason for hiding this comment

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

Do we have a list of packages (or is there a way to determine) which fail to build in isolated mode?

@dean0x7d
Copy link
Member Author

dean0x7d commented Sep 25, 2023

It's impossible to tell. It's any package from pypi.org that has a setup.py file that assumes other scripts from the same directory are importable. A recent example is this package (which is a dependency of a dependency) that trips on this line: https://github.com/PythonCharmers/python-future/blob/3dc7acc8e5a4266df6c823b9350a731dd7df6124/setup.py#L86

Copy link
Contributor

@sjlamerton sjlamerton left a comment

Choose a reason for hiding this comment

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

⛩️

The issue was that our embedded Python could pick up extra Python
packages installed in the user's home directory. Python adds user
paths by default unless instructed otherwise. The `._pth` file puts
it into isolated mode. See the docstrings of `_isolate()` for all
the details.
@dean0x7d dean0x7d force-pushed the fix-double-include branch from d50ffd2 to bb0c9bb Compare October 2, 2023 15:28
@dean0x7d dean0x7d enabled auto-merge (rebase) October 2, 2023 15:29
@dean0x7d dean0x7d merged commit 250377b into main Oct 2, 2023
7 checks passed
@dean0x7d dean0x7d deleted the fix-double-include branch October 2, 2023 15:49
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Python 3.10.x fails to find ssl with openssl 3.x
3 participants