pip/_vendor/pep517 is in sys.path when executing setup.py

[hexagonrecursion]

This causes issues when importing certain libraries in setup.py eg colorlog

pyproject.toml

[build-system]
requires = ["setuptools", "wheel", "colorlog"]
build-backend = "setuptools.build_meta"

setup.py

import sys
from pprint import pprint
from setuptools import setup

pprint(sys.path)
setup()
exit(1)

Relevant part of the output:

  ['/home/user/pip/src/pip/_vendor/pep517',
   '/tmp/pip-build-env-ypml46ei/site',
   '/home/user/.conda/envs/hello/lib/python39.zip',
   '/home/user/.conda/envs/hello/lib/python3.9',
   '/home/user/.conda/envs/hello/lib/python3.9/lib-dynload',
   '/tmp/pip-build-env-ypml46ei/overlay/lib/python3.9/site-packages',
   '/tmp/pip-build-env-ypml46ei/normal/lib/python3.9/site-packages']

pypa/pip#8887 (comment)
The end result of this is that if anyone's build relies on a library with the name of any files in the vendored copy of the pep517 library, they'll encounter this same problem.

pypa/pip#8887 (comment)
I was confused why out of the dozens of libraries pip vendors only pep517 is in the path. I was thinking maybe pep517 is not vendored correctly. bcc execsnoop cleared that up:

PCOMM            PID    PPID   RET ARGS
pip              21719  18141    0 /home/user/.conda/envs/hello/bin/pip install -e ./hello-setup/
uname            21721  21719    0 /usr/bin/uname -rs
python           21722  21719    0 /home/user/.conda/envs/hello/bin/python /home/user/pip/src/pip install --ignore-installed --no-user --prefix /tmp/pip-build-env-xmo5gc8z/overlay --no-warn-script-location --no-binary :none: --only-binary :none: -i https://pypi.org/simple -- setuptools wheel colorlog
uname            21726  21722    0 /usr/bin/uname -rs
python           21727  21719    0 /home/user/.conda/envs/hello/bin/python /home/user/pip/src/pip/_vendor/pep517/_in_process.py get_requires_for_build_wheel /tmp/tmp1trhhp23

Note the last line: pip runs src/pip/_vendor/pep517/_in_process.py as a subprocess. This is why its parent directory is in the path.

I want to fix this. I was instructed to open an issue in this repo.

[hexagonrecursion]

I can confirm that the process is being spawned by the following code:
https://github.com/pypa/pep517/blob/a2d884976eaf93225dee151137476a042008d8dd/pep517/wrappers.py#L274-L278

[hexagonrecursion]

Possible solutions:

1. Move _in_process.py into its own directory. This directory will then end up in sys.path, but if the only file in it is _in_process.py this should not be a big deal. Right?
2. Have _in_process.py delete sys.path[0]

[hexagonrecursion]

edit:
Never mind. Figured out how to bypass that: move the above code into init.py of a new subpackage.

Issue with option 1: the path to _in_process.py is obtained via importlib.resources.path()
https://github.com/pypa/pep517/blob/a2d884976eaf93225dee151137476a042008d8dd/pep517/wrappers.py#L23-L26

https://docs.python.org/3/library/importlib.html#importlib.resources.path emphasis mine

resource is the name of the resource to open within package; it may not contain path separators and it may not have sub-resources (i.e. it cannot be a directory).