Reduce the number of paths through the code

[pfmoore]

We have way too many special cases in how we do installs. I just discovered a new one today - if the user doesn't have wheel installed, and is installing from source, and doesn't have a pyproject.toml, then we do setup.py install and bypass building a wheel. As a result (for example) the checks that installed script wrappers are on PATH don't get run.

We should reduce these special cases. It's likely we'll need some sort of deprecation or behaviour change warning, to ease migration, but ideally we should converge on a single installation path (which will be PEP 517, in due course).

[pradyunsg]

I strongly agree.

I genuinely think that documenting internals properly, #4575, #5051 and similar internal changes will be really helpful for identifying which paths we should consider removing.

There were (and still likely are) a lot of "action at a distance" lines -- they make these special cases harder to identify. And removing behaviors will lead to people who'd be annoyed -- ideally we should still have some way for people to switch to at the time of removal unless it's not an obscure case.

[pradyunsg]

(deleted duplicate comment, posted early by mistake)

[pfmoore]

ideally we should still have some way for people to switch to at the time of removal.

Not quite sure what you meant here, but IMO yes, this will involve behaviour changes. And no, I don't think we should always provide ways to get the original behaviour back. We should provide deprecation warnings, but we're not obliged to preserve old behaviours indefinitely. It'll be a matter of judgement, but that doesn't mean we can't do it. For example, I don't see any long-term value in preserving the setup.py install path over building a wheel and installing it now that we have PEP 518 support.

[dstufft]

FWIW, in my head I always figured we'd simplify our special cases as part of deprecating and ultimately killing the non PEP 517 support.