System setuptools leaks into isolated build environment

[dalcinl]

Description

My project uses a custom in-tree build backend that wraps setuptools.build_meta and its build-system hooks implementation. I'm trying to add support for editable installs. I'm running on a Fedora 36 box, and the system has setuptools 59 installed via the system package manager. Therefore, I request a higher setuptools version in pyproject.toml. Looks like pip actually installs the higher setuptools, but eventually the older one from the system is picked.

Expected behavior

pip should use the requested version of setuptools.

pip version

22.2.2

Python version

3.10

OS

Fedora Linux 36

How to Reproduce

• pyproject.toml

[project]
name = "foo"
version = "0.0.1"

[build-system]
requires = ["setuptools >= 64"]
build-backend = "builder"
backend-path = ["."]

• builder.py

def get_requires_for_build_editable(config_settings=None):
    import setuptools
    assert 0, f"{setuptools.__version__} {setuptools}"
    from setuptools import build_meta as backend
    return backend.get_requires_for_build_editable(
        config_settings,
    )

def prepare_metadata_for_build_editable(
    metadata_directory,
    config_settings=None,
):
    from setuptools import build_meta as backend
    return backend.prepare_metadata_for_build_editable(
        metadata_directory,
        config_settings,
    )

def build_editable(
    wheel_directory,
    config_settings=None,
    metadata_directory=None,
):
    from setuptools import build_meta as backend
    return backend.build_editable(
        wheel_directory,
        config_settings,
        metadata_directory,
    )

Note the line assert 0, f"{setuptools.__version__} {setuptools}" in get_requires_for_build_editable()!
I need that line to easily show the root of the issue.

Output

Use `pip` to install in editable mode:


$ pip install -e .
Defaulting to user installation because normal site-packages is not writeable
Obtaining file:///home/dalcinl/tmp/pip-bug
  Installing build dependencies ... done
  Checking if build backend supports build_editable ... done
  Getting requirements to build editable ... error
  error: subprocess-exited-with-error
  
  × Getting requirements to build editable did not run successfully.
  │ exit code: 1
  ╰─> [10 lines of output]
      Traceback (most recent call last):
        File "/home/dalcinl/.local/lib/python3.10/site-packages/pip/_vendor/pep517/in_process/_in_process.py", line 363, in <module>
          main()
        File "/home/dalcinl/.local/lib/python3.10/site-packages/pip/_vendor/pep517/in_process/_in_process.py", line 345, in main
          json_out['return_val'] = hook(**hook_input['kwargs'])
        File "/home/dalcinl/.local/lib/python3.10/site-packages/pip/_vendor/pep517/in_process/_in_process.py", line 144, in get_requires_for_build_editable
          return hook(config_settings)
        File "/home/dalcinl/tmp/pip-bug/builder.py", line 3, in get_requires_for_build_editable
          assert 0, f"{setuptools.__version__} {setuptools}"
      AssertionError: 59.6.0 <module 'setuptools' from '/usr/lib/python3.10/site-packages/setuptools/__init__.py'>
      [end of output]
  
  note: This error originates from a subprocess, and is likely not a problem with pip.
error: subprocess-exited-with-error

× Getting requirements to build editable did not run successfully.
│ exit code: 1
╰─> See above for output.

note: This error originates from a subprocess, and is likely not a problem with pip.

Note the AssertionError line:

AssertionError: 59.6.0 <module 'setuptools' from '/usr/lib/python3.10/site-packages/setuptools/__init__.py'>

I requested "setuptools >= 64" in my requirement, but the older system-wide setuptools is being used.

### Code of Conduct

- [X] I agree to follow the [PSF Code of Conduct](https://www.python.org/psf/conduct/).

[dalcinl]

I explicitly state that I DO NOT AGREE with being forced to agree with the PSF Code of Conduct to submit this issue. I ticked the box just because I cannot continue otherwise. I hope this requirement for issue submission is an oversight. If not, please close this issue and ignore my report.

PS: I already had this discussion within the setuptools project and added this clarification upon reporting an issue. Eventually, setuptools stop requiring people to agree to the CoC and changed it with an admonition remembering reporters that they are expected to follow the CoC.

[sbidoul]

Hi,

Thanks for the detailed report!

Would you mind trying the same with pip 22.1.3?

[dalcinl]

Would you mind trying the same with pip 22.1.3?

I don't see a pip 22.1.3 release on PyPI, nor a 22.1.3 tag in the git repository.

I've tried 22.1.2, same issue as reported above.

[sbidoul]

I've tried 22.1.2, same issue as reported above.

Thanks. I can reproduce with the system python on Ubuntu 20.

Within a virtualenv this seems to be correct, which probably explains why it has not been detected before.
Can you confirm it works in a virtualenv for you too?

[dalcinl]

Can you confirm it works in a virtualenv for you too?

Yep, if using virtualenv, everything looks OK.

[sbidoul]

Ok, thanks. That's going to be... interesting to debug :/

[pradyunsg]

There's an open issue for this somewhere already FWIW.

[pradyunsg]

It's the same class of problems as #6264 -- we're adding system paths in the virtual environment, with Debian/Ubuntu Python because of their patches (IIUC).

[dalcinl]

@pradyunsg Note I'm running Fedora 36, though. They do add some patches related to user site-packages (the place where I have my pip installed), but I do not believe these patches is the source of this issue.

[pradyunsg]

Hmm... It might still be the same root cause though; wherein the isolation is adding a system path when it shouldn't.

Can you share the output of print(sys.path) and sysconfig._main() from the subprocess that pip is invoking?

[pradyunsg]

And, does this failure also happen with non-editable installations?

[pradyunsg]

I explicitly state that I DO NOT AGREE with being forced to agree with the PSF Code of Conduct to submit this issue. I ticked the box just because I cannot continue otherwise. I hope this requirement for issue submission is an oversight. If not, please close this issue and ignore my report.

It's not an oversight. Making users explicitly opt in is an intentional choice.

Regardless of what you say, you're expected to follow the PSF CoC while interacting in this project's online spaces (and setuptools'). If you violate the CoC in your interactions here at any point, we'll take action according to the CoC as well. If you have concerns around that, you're free to not interact with the project. :)

[dalcinl]

If you have concerns around that,

Yes, I do have concerns.

you're free to not interact with the project. :)

Well, if that's your attitude, then I'm very sorry.

@jaraco I wrongly assumed that all this matter was already sorted out. Now I realize your update applied only to setuptools, and not PyPA as a whole. Looks like any bug report that I make in good faith to any of the PyPA projects will require explaining my point over and over again, and have to swallow the usual "if you don't like it, you are free to go way".

[jaraco]

Now I realize your update applied only to setuptools, and not PyPA as a whole.

That's right - we're a loose-knit group with shared goals, but little standardized policy, which in most cases benefits the projects, but does mean that policies like these are largely uncoordinated. I'd prefer if other PyPA projects followed my lead, based on the discussion in that thread, but they're welcome to create the policies and associated friction as suits their maintenance style.

[notatallshaw]

@jaraco I wrongly assumed that all this matter was already sorted out. Now I realize your update applied only to setuptools, and not PyPA as a whole. Looks like any bug report that I make in good faith to any of the PyPA projects will require explaining my point over and over again, and have to swallow the usual "if you don't like it, you are free to go way".

For reference for those who don't know the thread being refereed to it's here: https://discuss.python.org/t/what-to-do-with-contributors-who-refuse-code-of-conduct/13287

And FYI pradyunsg, one of the Pip maintainers, already stated their opinion on keeping CoC agreement on the thread you are referring to: https://discuss.python.org/t/what-to-do-with-contributors-who-refuse-code-of-conduct/13287/12

Sorry for being off topic but I think this thread is confusing for anyone who doesn't have the context.

[dalcinl]

And, does this failure also happen with non-editable installations?

Yep, I just tried (replacing "editable" with "wheel"), and the issue is still there, the old system setuptools is being used.
And again, installing in a virtual environment works fine, the newer setuptools from the tmp build environment is being used.

[dalcinl]

Can you share the output of print(sys.path) and sysconfig._main() from the subprocess that pip is invoking?

• sys.path (working directory: /home/dalcinl/tmp/pip-bug, pip installed in my user site-packages)

/home/dalcinl/tmp/pip-bug
/home/dalcinl/.local/lib/python3.10/site-packages/pip/_vendor/pep517/in_process
/tmp/pip-build-env-wa8k_c5k/site
/usr/lib64/python310.zip
/usr/lib64/python3.10
/usr/lib64/python3.10/lib-dynload
/usr/lib64/python3.10/site-packages
/usr/lib/python3.10/site-packages
/tmp/pip-build-env-wa8k_c5k/overlay/local/lib/python3.10/site-packages
/tmp/pip-build-env-wa8k_c5k/overlay/local/lib64/python3.10/site-packages
/tmp/pip-build-env-wa8k_c5k/normal/local/lib/python3.10/site-packages
/tmp/pip-build-env-wa8k_c5k/normal/local/lib64/python3.10/site-packages

• sysconfig._main()

Platform: "linux-x86_64"
Python version: "3.10"
Current installation scheme: "posix_prefix"

Paths: 
	data = "/usr/local"
	include = "/usr/include/python3.10"
	platinclude = "/usr/include/python3.10"
	platlib = "/usr/local/lib64/python3.10/site-packages"
	platstdlib = "/usr/lib64/python3.10"
	purelib = "/usr/local/lib/python3.10/site-packages"
	scripts = "/usr/local/bin"
	stdlib = "/usr/lib64/python3.10"
...

Note: my /usr/local tree is empty of Python stuff, I never sudo-install non-distro Python packages with pip, the {pure|plat}lib directories reported above do not exist.

[pradyunsg]

Consolidating this into #6264.