-
Notifications
You must be signed in to change notification settings - Fork 115
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
local imports to setup.py alias with PYTHONPATH when run from ../pep517/in_process/_in_process.py #373
Comments
For others concerned about script-local imports for setup.py, I was able to work around this using import sys
import os
# this is a fix for running within the pypa build package
# it ensures that only the local setup_helper is imported
# it preprends this file's path to the import path
sys.path[0:0] = [os.path.dirname(os.path.abspath(__file__))]
import setup_helper # noqa |
My recommendation would be to rename that helper to something less generic, eg. That said, if you actually have |
There's no name conflict - the CWD is not on path and calling the module something else would not help. This is the (only) reason the |
I will say that if I remove the aliased versions from PYTHONPATH, my setup_helper.py colocated with setup.py is imported and the build runs as expected using Regardless of whether it is considered a bug, it is unintuitive at least to me that the import semantics of setup.py changed using this more generic build interface. In that case, hopefully this issue documents it as an edge case for anyone who might encounter it. I don't think it is a "normal" module name conflict as it has to due with the expectation that setup.py is run as script and that its directory be the first element in sys.path as per https://docs.python.org/3/library/sys.html#sys.path. |
|
How do you remove the aliased versions from |
What do you mean? |
I am asking how @mccullerlp goes about removing the aliased versions from |
Some environment variables, like PYTHONPATH, interfere with Python. They should be cleared when constructing an isolated environment so that they do not cause anything from the original environment to leak into our new environment. Fixes pypa#373 Signed-off-by: Filipe Laíns <lains@riseup.net>
Some environment variables, like PYTHONPATH, interfere with Python. They should be cleared when constructing an isolated environment so that they do not cause anything from the original environment to leak into our new environment. Fixes pypa#373 Signed-off-by: Filipe Laíns <lains@riseup.net>
Some environment variables, like PYTHONPATH, interfere with Python. They should be cleared when constructing an isolated environment so that they do not cause anything from the original environment to leak into our new environment. Fixes pypa#373 Signed-off-by: Filipe Laíns <lains@riseup.net>
These are aliased versions of 'setup_helper.py' from other projects in my PYTHONPATH. In this case, clearing them consists of just I'll also note that I am using pyproject.toml [build-system]
requires = [
"setuptools>=45",
"wheel",
]
build-backend = "setuptools.build_meta" in case this issue resides upstream with the backend. |
I am using a helper module "setup_helper.py" to add some consistency checking to my setup.py build process. The setup_helper.py is in the same folder as setup.py and is imported correctly when using "python setup.py".
When using python -m build, I find that another package that I have that is on my PYTHONPATH with its own setup_helper.py in the sys.path is getting imported and called rather than the local one. I've tried adding back "." to the sys.path and haven't yet found a workaround. I've found that this is happening when sys.argv[0] or
__main__.__file__
point to this _in_process.py runner.`
It's a subtle and unexpected error to have the import path handling change with this build system. I don't understand why this is happening to help it though.
The text was updated successfully, but these errors were encountered: