Disallow explicitly passing install-location-related arguments in --install-options

What’s the problem this feature will solve?

Currently the --install-option parameter allows passing arbitrary arguments to setup.py for packages using the legacy-installation path. If any options/flags that control install location are passed, such as:

• --exec-prefix
• --home
• --install-base
• --install-data
• --install-headers
• --install-lib
• --install-platlib
• --install-purelib
• --install-scripts
• --prefix
• --root
• --user

then it causes issues. Not every package uses setup.py, so in the general case this causes legacy packages to be installed with the the scheme provided in --install-option and PEP 517/wheel packages to be installed with the scheme pip is aware of. This has already hit two users (#7253, #7240).

Pip knows how to use scheme information properly for PEP 517, wheel, and legacy installs. Enforcing that pip is the only one passing this kind of information will make the user experience more consistent.

Describe the solution you’d like

Explicitly fail pip install if --install-option includes any of the above arguments, whether provided on the command-line or in a requirements file.

In addition to the consistent user experience, this would also allow pip to pass the more explicit

• --install-{purelib,platlib,headers,scripts,data} (for install)
• --install-dir, --script-dir (for install -e)

to setup.py instead of the current --prefix, --home, --root, --user, and --install-headers.

This may also be required to implement PEP 582 (__pypackages__) since doing legacy installs to a plain lib directory isn’t possible with the current arguments being passed to setup.py, and passing an explicit --install-lib would break any usages of the other arguments in --install-option.

IMO this could be implemented without deprecation because the current behavior demonstrated in #7253 and #7240 causes failures in non-obvious ways, and the remediation is simple in most cases - just pass the parameters to pip instead.

Alternative Solutions

• do nothing - as we accumulate more features that conflict with these arguments being passed to --install-option we will get more support tickets. These will taper off eventually as people stop using these flags in order to install non-legacy packages. We eventually forget that the user can pass these options, and implement new features without worrying about it.
• automatically determine a scheme based on --install-option - this defeats the purpose of having pip-level arguments
• only fail the install if the scheme in --install-option conflicts with the one specified at the pip level - this is more friendly, but I feel that it would also be more confusing and add to the implementation burden in pip (reconciling --install-option across different packages in a requirements file)

Additional context

• #7253 - user already having a related issue
• #7240 - user already having a related issue
• #6052 - without executing the current proposal the refactoring mentioned here gets much more difficult, since we must continue to pass --home, --prefix, --user, and --root to setup.py

[BastienFaure]

@chrahunt I’ve been looking along this thread and haven’t been able to find my answer, hopefuly you can give me an answer 😃 I previously legeraged --install-option="--install-scripts=/custom/path/" to deploy only scripts to a specific location but this is now rejected with the recents updates. Is there still a way through pip to install scripts to a custom location without moving the whole package ?

Thank you

[chrahunt]

So, unfortunately, I didn’t include --install-dir and --script-dir in the list of things to get checked. This is supported by its usage in this test, which started to fail when I refactored editable installation to explicitly pass --script-dir to setup.py. These values are only relevant to editable installs.

As a result we can’t do a full replacement now like I was intending. We can still take an approach like I described in #7309 (comment), and it should be quite a bit easier since there are only two values and they map directly to the scheme values we should use (overriding “scripts” and “lib_dir”). We could do that while waiting another 2 releases before disallowing --install-dir and --script-dir and still get the majority of the benefits.