Repository navigation
Respect top-level "constraints" file when populating isolated build environments #8439
Description
Environment
- pip version: 20.1.1
- Python version: 3.8.2
- OS: Linux
pip freeze output:
attrs==19.3.0
certifi==2020.4.5.2
chardet==3.0.4
docutils==0.16
flit==2.3.0
flit-core==2.3.0
idna==2.9
punq==0.4.1
pytoml==0.1.21
requests==2.23.0
urllib3==1.25.9
Description
Installing a package using a PEP 517 backend with build isolation enabled results in an install_requirements call using the return value of backend.get_requires_for_build_wheel(), which generates and runs a pip install command. Constraints files passed to the outermost pip install command are not reflected in the generated command.
This means that, at least when using flit, a local install with build isolation will fail if it's relying on a constraints file to specify paths to dependencies that are only available locally.
(The other build backends I checked don't require the runtime requirements in the isolated environment. I brought this up in the flit repo first in pypa/flit#354)
Expected behavior
Given two projects, a dependency and a dependent, with the dependent using flit, and the dependency not present in an index, the command pip install -c path/to/constraints.txt path/to/dependent, where the constraints file has a line like name-of-dependency @ file:///absolute/path/to/dependency should succeed.
How to Reproduce
- Create a "dependency" project with a name not present in pypi
- Create a "dependent" project that depends on the dependency, using flit
- Create a
constraints.txtfile that at least contains a direct reference linking the name of the dependency to its absolute path
4 Runpip install -c constraints.txt ./dependent, assuming the constraints file and the project directories are next to each other
Output
$ ls
constraints.txt dependency_bleh dependent
$ cat constraints.txt
dependency_bleh @ file:///absolute/path/of/pwd/dependency_bleh
dependent @ file:///absolute/path/of/pwd/dependent
$ pip install -c constraints.txt ./dependent
Processing ./dependent
Installing build dependencies ... done
Getting requirements to build wheel ... done
Installing backend dependencies ... error
ERROR: Command errored out with exit status 1:
command: <venv>/bin/python3.8 <venv>/lib/python3.8/site-packages/pip install --ignore-installed --no-user --prefix /tmp/pip-build-env-67rnvdf5/normal --no-warn-script-location --no-binary :none: --only-binary :none: -i https://pypi.org/simple -- dependency_bleh
cwd: None
Complete output (2 lines):
ERROR: Could not find a version that satisfies the requirement dependency_bleh (from versions: none)
ERROR: No matching distribution found for dependency_bleh
----------------------------------------
ERROR: Command errored out with exit status 1: <venv>/bin/python3.8 <venv>/lib/python3.8/site-packages/pip install --ignore-installed --no-user --prefix /tmp/pip-build-env-67rnvdf5/normal --no-warn-script-location --no-binary :none: --only-binary :none: -i https://pypi.org/simple -- dependency_bleh Check the logs for full command output.
Activity
mwchase commentedon Oct 10, 2020
PIP_CONSTRAINT=constraints.txt pip install dependentturns out to be an acceptable workaround for my purposes. Probably better than the other workarounds I've used since I filed this.EDIT: Also, FWIW, if the version can be calculated just by AST analysis, flit now works with the command I gave above. After I remembered this, I tested with the old command, then verified both commands against a setup that deliberately broke flit's AST analysis. When AST analysis fails, the original command fails, and the workaround does, in fact, work.
mwchase commentedon Nov 18, 2020
I should have kept up with the behavior of the new resolver. It appears that #8210 in a sense, breaks both the problem and the solution. I'll investigate more comprehensive workarounds that are outside the scope of this issue.
I suppose this issue should be left open, because it's still relevant to the intended behavior of constraints files.
Enable again build isolation with proper pinning of build dependencies (
fast-foward to upstream (#1)
apljungquist commentedon May 17, 2021
It appears another consequence of this is that hash-checking is not enabled for build system requirements, not even if
--require-hashesis set on the primary pip command. This is particularly surprising given the emphasis on secure default behaviors w.r.t. hash checking described in the documentation.Using the workaround suggested earlier hashes are checked also for build system requirements, assuming hashes are specified for at least one package in the constraints.
[-]generated pip commands do not respect constraints files in outer install command[/-][+]Respect top-level "constraints" file when populating isolated build environments[/+]chaoflow commentedon Dec 1, 2022
Could somebody clarify what the status is with recent pip? Grepping for
PIP_CONSTRAINTproduces no results.As @apljungquist already pointed out, hashes must be checked also for build dependencies. Is there anything to help make this?
pradyunsg commentedon Dec 1, 2022
PIP_CONSTRAINT is supported via https://pip.pypa.io/en/stable/topics/configuration/#environment-variables
notatallshaw commentedon Oct 18, 2025
There is now a dedicated
--build-constraintflag: #13534, I believe this closes this issue out.As of pip 25.3 if you want to use a constraints file for both run time and build time constraints you do
--constraint constraints.txt --build-constraint constraints.txt, but importantly you can provide different files or only provide one or the other.