local imports to setup.py alias with PYTHONPATH when run from ../pep517/in_process/_in_process.py

[mccullerlp]

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.

[mccullerlp]

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

[FFY00]

My recommendation would be to rename that helper to something less generic, eg. myproject_setup_helper. We do not consider this a bug, as it is just normal module name conflict.

That said, if you actually have PYTHONPATH set, and the path is being injected via that mechanism, I would probably consider that a bug when running in isolation.

[layday]

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 __legacy__ setuptools backend was devised, because pep517 does not place the CWD on sys.path.

[mccullerlp]

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 python -m build. I'll probably code defensively and use a less generic name, but I wanted to raise the issue.

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.

[FFY00]

PYTHONPATH should not interfere with isolated builds, so I am marking this as a bug.

[layday]

How do you remove the aliased versions from PYTHONPATH?

[FFY00]

What do you mean?

[layday]

I am asking how @mccullerlp goes about removing the aliased versions from PYTHONPATH so I can get a better idea of the issue.

[mccullerlp]

These are aliased versions of 'setup_helper.py' from other projects in my PYTHONPATH. In this case, clearing them consists of just export PYTHONPATH= before the build. Sloppy, I know - thus the edge case. I haven't checked if aliasing occurs from installed packages or just PYTHONPATH.

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.