-
Notifications
You must be signed in to change notification settings - Fork 3k
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 and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add an option for pip to manage a different "environment" #11307
Comments
This actually don’t necessarily need to depend on #4575? (Although it’d of course make this much easier to implement.) With pip being distributable as a standalone application, the flag could be implemented by simply packaging pip into that, and create a subprocess to do the actual work against the specified interpreter. |
This functionality doesn't require there to be a specified interpreter. It would act as a (more complete) replacement for As a straw-man proposal, I'm suggesting a global pip option |
Quick set of thoughts before I move over to my work laptop:
Beyond that, IIUC, there's three "points" of coupling with the currently running interpreter:
I think, to make pip work correctly with the various flags that we have, we should consider what our flags do on this front today. I believe we don't have anything that affects 2. We have flags that should affect 3 and don't. We also don't have any way for a user to specify all of these, which we probably should. A |
OK, I got over-excited by the results of my investigations, and as a result, generalised my findings way beyond what they justified. @pradyunsg you're absolutely right, a On the other hand, the Apologies for the confusion. I find issues a fairly clumsy way of handling the sort of "exploring the design space" work that I'm currently doing - but I don't know of any other, better way of sharing my findings (and unfortunately for the rest of you, I work better by sharing progress as I go along 🙄) So to summarise:
Both of these seem like reasonable new features to add - does anyone have any reservations regarding either of them? Footnotes
|
Draft PR for this at #11320. @pradyunsg's work on |
We now have a |
What's the problem this feature will solve?
At the moment, pip can only fully1 manage the current Python environment. This makes it hard to have environments without pip installed (for example, when preparing a zipapp, or an embedded Python installation).
Being able to specify a target "environment" (in the sense of a set of paths like
sysconfig
scheme) which pip can manage, would allow a single shared pip to be used for multiple Python environments.Describe the solution you'd like
Add a global option to pip that sets the "environment" to be managed. The UI for this option is yet to be decided - in the most explicit case, values are needed for the 5 sysconfig paths that pip can install data into, but shortcuts for common cases would be important for a good user experience.
All pip commands will use the specified environment.
Alternative Solutions
--target
,--root
and--prefix
options all attempt to handle this, but they lack support for upgrades and uninstalls, as well as not being integrated with informational commands likelist
.python
executable works, but only when the target environment is a virtual environment. This does not cover cases like preparing a zipapp, or installing into the library area of an app that embeds Python.python -m pip
command.Additional context
This is closely related to #4575. A lot of the discussion on that issue covered handling environments that "shadow" each other (user shadowing system, and
--use-system-site
virtual environments). This issue explicitly avoids that problem, focusing on the case of a single standalone environment, with shadowing being left as an issue for how the user sets up theirsys.path
.This proposal doesn't stand a chance of working with the "legacy" direct
setup.py
install method (for editables or normal installs), as that method delegates installation to setuptools, and it is impractical to force setuptools to conform to the scheme selected in pip1. So maybe it's time to finally pull the plug on that method? What remains to do to make that happen? At an absolute minimum, we should make the legacy install method fail if a custom scheme is set by this option.Testing will be a possible issue. In theory, we should test as much of pip's functionality as possible with a custom scheme, as well as with the default scheme. But that will be a fairly massive increase in our already large test times2. I feel like it would be worth reorganising the test suite to have a "core functionality" section that's run on a matrix basis (normal, zipapp, custom scheme, ...) with the remaining functional tests being normal scheme only (but if we do that, are we just crossing our fingers that there's no edge cases?) I don't feel anything like confident enough in my understanding of our test suite to tackle something like this, though. For now, I'll probably just add "custom scheme" tests as I go, ignoring the test runtime issue, and leave refactoring the test suite to someone with more expertise...
Code of Conduct
Footnotes
The
--target
,--root
and--prefix
options only apply topip install
. ↩ ↩2 ↩3Particularly if we also add testing the zipapp version, which has the same sort of "everything should work the same" problem. ↩
The text was updated successfully, but these errors were encountered: