The issue is about exceptions bubbling up to the interface level, not about crashing pip. For example, if some class raises notimplemented error and pip interprets that to mean it should call build_wheel.

On Aug 25, 2017 1:23 PM, "Paul Moore" <p.f.moore@gmail.com> wrote:
On 25 August 2017 at 18:06, xoviat <xoviat@gmail.com> wrote:
> Is pip going to fall back to building a wheel directly if any other error is
> raised? That's what happens with setup.py install. If so, then it may be
> fine if unexpected exceptions bubble up.

Given that hooks need to be called in a subprocess (see
https://www.python.org/dev/peps/pep-0517/#id15, "Frontends should call
each hook in a fresh subprocess, so that backends are free to change
process global state") there's no "bubbling up" involved at all. The
frontend code would be something along the lines of

hook_stub = '''
import backend
try:
    backend.build_sdist(...)
except NotImplementedError:
    sys.exit(1)
sys.exit(0)
'''
# Or...
hook_stub = '''
import backend
if backend.build_sdist(...) == NotImplemented:
    sys.exit(1)
sys.exit(0)
'''

if subprocess.call([sys.executable, "-c", hook_stub]) != 0:
    # We didn't build a sdist

There's little or no opportunity here for letting exceptions bubble up
to the user, or passing complex data back to the frontend. Ultimately,
it's pretty much immaterial which form of reporting is used.

Paul