Reduce the number of paths through the code · Issue #5204 · pypa/pip (original) (raw)

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service andprivacy statement. We’ll occasionally send you account related emails.

Already on GitHub?Sign in to your account

Open

pfmoore opened this issue

Apr 10, 2018

· 4 comments

Open

Reduce the number of paths through the code #5204

pfmoore opened this issue

Apr 10, 2018

· 4 comments

Comments

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).

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.

(deleted duplicate comment, posted early by mistake)

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.

This was referenced

Jun 22, 2019

This was referenced

Dec 1, 2019

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.