I would slightly change this to spell it like --scheme {global,user,venv}

Oh, and this would let you set a default scheme for yourself using the configuration toolchain.

@dstufft @pfmoore I would like to know what you think about this. :)

In principle this sounds like a reasonable thing to do - but I'm afraid I've got some personal priorities at the moment that mean I don't really have time to think through the implications.

So count me as in favour in principle, but not really able to provide a detailed review at the moment, sorry.

Cool. Thanks! :)

Just noting that I briefly thought that --scheme may not be a good name for this option, due to the potential collision with the concept of installation schemes in sysconfig: https://docs.python.org/3/library/sysconfig.html#installation-paths

However, I subsequently realised that these uses are actually the same use case - the new pip level option is just a helper to select the desired scheme without having to specify the exact platform appropriate scheme name as defined in sysconfig.

Linking to #2418 since I somehow always forget there was an attempt at making --user behaviour default.

concept of installation schemes in sysconfig

This is, actually, nice that the names here and there match. :)

This came up in #4809 where I suggested being able to pip list only packges related to one scope (now it combines both system and user packages, making it impossible to say which package comes from where).

I've gone ahead and made a PR for this -- #4871.

Thoughts @dstufft, @xavfernandez?

Maybe Barry Warsaw (his name's on the Debian patch to pip; #1668 would be fixed as a part of that PR) should be pinged for this discussion?

How does --target mode of operation relate to schemes? It feels like --target essentially is another type of scheme and treating it as such would potentially solve many bugs pertaining to --target option.

Not sure if I missed it, how would this interact with the set of packages available for import in a setup.py-based install, or a PEP 517 install using --no-build-isolation?

Also, is the assumption that for determining whether a dependency is already installed we'd have some of these schemes "inherit" the packages from the packages that would be available in another? Like

• user considers packages in system
• local considers packages in user and system only if system site packages is enabled
• system doesn't consider any others
• target doesn't consider any others (or it may be configurable -I think we've seen use cases going both ways)

No changes on that front. This would only affect how a package is installed / unpacked, not how it's built.

Things that are currently importable at build time, would stay importable -- basically anything that's on sys.path when running.

Poking here for feedback on #7164.

It looks like @takluyver in #7164 (comment) has a nice plan for stopping some of the damage of defaulting to write to system wide packages. #7002 That should hopefully stop much of the damage experienced by newbies. Thank you, thankyou, thanksssss to all involved! 🎈🎉

(Re?)iterating that this change is still relevant in a post #7002 world, since this is an internal refactoring-related issue in pip.

I'd expect us to start by making refactors to decouple the scheme from the various parts of our codebase (like @chrahunt has started!) and once that's completely/fairly done; we'd start working on the user-facing changes.

I agree this will hopefully improve the current inconsistent behavior. For example using Python 3.11.3 venv with pip 22.3.1 on Linux, I am able to install a package with the --user option, but if I attempt to uninstall the same package using the same venv/pip, it refuses indicating package is "outside environment" and "Can't uninstall 'mypackage'. No files were found to uninstall." I would expect the uninstall to work given the install was permitted.

If you have a sudo account, use this command.
sudo dnf remove python3-requests

For example, Amazon Linux 2023 have this issue.

I'm trying to move all my system-level wheels (I use Ubuntu) to my user level, so it would be nice to have a --system flag, since it already has a --user flag.

Sorry, what would that mean and how would it be useful?

I have a series of Python packages installed over apt, but the problem is: since it's necessary that the developers release a new downstream package version taking more time than the upstream release, I usually have to keep some applications in an older version, so I'm checking what Python-based tools I can install directly with pip --user. Today I developed this command: comm -23 <(pip list | awk 'NR>2 {print $1}'|sort) <(pip list --user| awk 'NR>2 {print $1}'|sort). This will say what are the Python packages that are not installed in my user. But it should be better to be able to see this with pip list --system, since we already have pip list --user. I hope I could explain me better now.