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.

[dstufft]

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.

[pradyunsg]

Shout-out to @seppeljordan for actually fixing this! ^.^