pypa
pip should ignore `[install] no-deps = true` in pip.conf when setting up isolated build environment.
Description
AFAICT, having
[install]
no-deps = true
in one's pip.conf (which is my case as I prefer manually resolving dependencies (or rather with some custom scripts) in my work environment) leads to dependencies also not being installed when setting up the isolated build environment (i.e. the pip install calls when setting up that environment will also honor no-deps = true), but that makes the build fail as build-time dependencies will fail to import due to missing their own dependencies, and that's not something I (as a user) can manually fix, as the entire build-time environment only exists for the duration of the invocation of pip.
Expected behavior
Setting up the build environment should ignore [install] no-deps = true. Or, if that sounds too special-cased, perhaps there can be some way to say "nested pip calls during the setup of the build environment should use a different pip.conf".
To be clear, I understand that [install] no-deps = true makes me responsible for handling dependencies myself, but in the case of build-time nested dependencies in an isolated build environment, there is no time interval where I can actually do that.
pip version
22.1.2
Python version
3.10
OS
Arch Linux
How to Reproduce
In a clean venv and empty tmpdir:
$ printf '[install]\nno-deps = true' > pip.conf
$ PIP_CONFIG_FILE=pip.conf pip install -v --no-binary=scikit-image scikit-image
scikit-image has a build-time dependency on pythran, which has an install-requires on gast; this install-requires is not honored.
Output
Using pip 22.1.2 from /tmp/testenv/lib/python3.10/site-packages/pip (python 3.10)
Collecting scikit-image
Downloading scikit-image-0.19.3.tar.gz (22.2 MB)
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 22.2/22.2 MB 10.1 MB/s eta 0:00:00
<elided>
Installing collected packages: pythran, wheel, setuptools, packaging, numpy, Cython
Successfully installed Cython-0.29.30 numpy-1.21.4 packaging-21.3 pythran-0.11.0 setuptools-59.4.0 wheel-0.37.1
Installing build dependencies ... done
Running command Getting requirements to build wheel
Traceback (most recent call last):
<elided>
File "/tmp/pip-build-env-nosq_n6m/overlay/lib/python3.10/site-packages/pythran/passmanager.py", line 14, in <module>
import gast as ast
ModuleNotFoundError: No module named 'gast'
error: subprocess-exited-with-error
× Getting requirements to build wheel 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.
full command: /tmp/testenv/bin/python /tmp/testenv/lib/python3.10/site-packages/pip/_vendor/pep517/in_process/_in_process.py get_requires_for_build_wheel /tmp/tmpng4ao8h5
cwd: /tmp/pip-install-eos0zrxs/scikit-image_43ca98b65312486da4e3637012339511
Getting requirements to build wheel ... error
error: subprocess-exited-with-error
× Getting requirements to build wheel 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.
Code of Conduct
- [X] I agree to follow the PSF Code of Conduct.
IMO this is a valid issue, but I'm -1 on trying to special-case no-deps. I think what we need to do is to have a more general mechanism that allows users to control config settings for the build environment. That will involve looking at the trade-off between people like yourself who put settings in their config that are inappropriate for the build environment, versus people who have settings like proxy information, which must be used by the build.
In general, though, I think that putting behaviour-altering settings like --no-deps (and others that I've seen like --no-binary=:all:) in global config is a bad idea, because it fundamentally changes what "pip" does in a way that makes it impossible for tools (whether build isolation, or other 3rd party tools) to do a "normal" install of a package. Maybe the right solution here is actually to simply disallow such options in config files in the first place...
Maybe the right solution here is actually to simply disallow such options in config files in the first place...
While I would prefer a fix that keeps the previous workflow still possible, I agree that in the absence of such a fix, the option should just be disallowed in config files rather than being present but fragile.
In general I think we should very carefully review how we populate the build environment right now, pass --isolated to the subprocess so the behaviour is deterministic, and add additional flags to control build environment population.
