pip: Install with --no-binary ignores PEP 517 build system
Environment
- pip version: 19.0.1
- Python version: 3.7
- OS: Linux
Description
In a clean environment, run:
pip install --no-binary :all: flit
The output includes this:
Skipping bdist_wheel for flit, due to binaries being disabled for it.
...
Running setup.py install for flit ... error
Complete output from command /home/takluyver/miniconda3/envs/pip19/bin/python -u -c "import setuptools, tokenize;__file__='/tmp/pip-install-ud6iwhp3/flit/setup.py';f=getattr(tokenize, 'open', open)(__file__);code=f.read().replace('\r\n', '\n');f.close();exec(compile(code, __file__, 'exec'))" install --record /tmp/pip-record-wsv_33qq/install-record.txt --single-version-externally-managed --compile:
Traceback (most recent call last):
File "<string>", line 1, in <module>
ModuleNotFoundError: No module named 'setuptools'
Pip 19 is aware of PEP 517, and uses it if you do pip wheel --no-binary :all: flit
(the output includes Building wheel for flit (PEP 517) ... done
). But when installing from an sdist, it seems to default to running setup.py install
instead of building a wheel using the PEP 517 backend and installing that.
This is a problem in practice because pip does respect the PEP 518 build dependencies and create an isolated build environment, without setuptools. Setuptools is not required to build with the PEP 517 backend, but it is if you use the fallback setup.py
script.
It appears that the no-binary option disables the ‘build a wheel and install that’ pathway. But I think that option is generally taken to mean ‘download the sdist rather than the published wheel’. The plan is for all PEP 517 installations to work by building a wheel and then installing that.
About this issue
- Original URL
- State: closed
- Created 5 years ago
- Reactions: 3
- Comments: 22 (22 by maintainers)
Commits related to this issue
- Filter out 'jeepney' and 'entrypoints' from homebrew resources This is a workaround for pypa/pip#6222. It should not be a permanent change. — committed to marstr/azure-cli by marstr 5 years ago
- Update Homebrew Formula to install in Virtualenv (#8744) * Updating Homebrew Formula to use a virtualenv. This brings us into conformance with the guidelines for how to install Python applications... — committed to Azure/azure-cli by marstr 5 years ago
- maintenance script: fix bump_and_vendor_python_requirements.py Introduce temporary workaround for a bug in Pip 19+ (https://github.com/pypa/pip/issues/6222) that makes this script fail. Change-Id: I... — committed to clipos/toolkit by ngodinho-anssi 5 years ago
- Implement requirement installation for PEP 517 conform packages without setup.py The idea of this patch is that we build a wheel and install that whell when we install a requirement from source that ... — committed to seppeljordan/pip by seppeljordan 5 years ago
- mgr/dashboard: download setuptools_scm explicitly otherwise we will fail to install the build dependencies of `lazy-object-proxy` from the wheelhouse. as `lazy-object-proxy` does not add `setuptools_... — committed to tchaikov/ceph by tchaikov 5 years ago
- install-deps.sh: download wheel using 'pip wheel' otherwise we will fail to install the build dependencies of `lazy-object-proxy` from the wheelhouse. as `lazy-object-proxy` does not add `setuptools_... — committed to tchaikov/ceph by tchaikov 5 years ago
- install-deps.sh: download wheel using 'pip wheel' otherwise we will fail to install the build dependencies of `lazy-object-proxy` from the wheelhouse. as `lazy-object-proxy` does not add `setuptools_... — committed to vshankar/ceph by tchaikov 5 years ago
- install-deps.sh: download wheel using 'pip wheel' otherwise we will fail to install the build dependencies of `lazy-object-proxy` from the wheelhouse. as `lazy-object-proxy` does not add `setuptools_... — committed to mkogan1/ceph by tchaikov 5 years ago
- install-deps.sh: download wheel using 'pip wheel' otherwise we will fail to install the build dependencies of `lazy-object-proxy` from the wheelhouse. as `lazy-object-proxy` does not add `setuptools_... — committed to mkogan1/ceph by tchaikov 5 years ago
Yea,
--no-binary
should only be able what format we source a package from, not whether or not we route things through wheels to begin with, or whether or not we cache them.