-
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
Option to look for pip.conf in conda environment #5060
Comments
Related point that we may want to consider is using a different configuration file for when |
Should add the |
I'm probably fine with it being at FYI, maybe not relevant here, but the canonical way to tell if a directory is a conda environment (and the way conda itself uses) is |
Thoughts @pfmoore? Would this be something pip would be interested in and/or accept a patch for? |
@jakirkham I assume you're referring to the Having I'd suggest that conda environments follow the core Python standard and set |
Honestly don't really know the pip codebase well enough to propose where it should go. Was reading the docs, which sparked the question. :) Interesting. Not sure to what extent using Can think of a few tricky cases though. There may be more. Not totally sure the implications off the top of my head, but we'd have to be sure we understand what
|
Cool, I thought you were referring to what's in the code. I assume you were looking in the docs here. Pip doesn't look at # finally virtualenv configuration first trumping others
if running_under_virtualenv():
yield kinds.VENV, [venv_config_file]
|
That sounds right. Ah ok thanks for the info. What does So if we just drop a config file in |
From the code I quoted, such a config file will only be used if you're in a virtualenv (i.e.
|
So I think it is important to point out that AFAIK OTOH As a result of this, it's quite easy to have a version of Python installed in the On a different point, the Looking at the search priority might help to highlight the conceptual differences. Conda users typically think of each environment as being its own siloed |
If I understand conda correctly, I don't think that the requested feature is really specific to conda (even though the original ask suggests that it is). I think it might be better worded as adding a config file that is specific to the actual Python install. On a Windows machine with the Python.org installers, this might be located at |
Thanks @dstufft. Agree that Python installers (batteries included) seems like an overlapping use case with similar end goals ( even if I wasn't thinking of that initially ;). |
So, should we just unconditionally have @pfmoore @dstufft Would you be fine with changing the "venv" to "site" for pip config, in 10.0.0? Otherwise, we could have a transition to remove venv references in configuration over the standard deprecation cycle, removing venv references in pip 11/12, if we want. I'm fine with either. |
@pradyunsg I'm not sure that unconditionally having This is not something I'm wiling to grant an exception for to put it in 10.0.0, as it's not a bug fix but a new feature. And regardless, I don't see why we should change |
I got that feeler (unconditional addition) from Donald's comment.
I guess I'm trying to get too much into 10.0.0, as I said, I'm fine with
this happening after pip 10.0.0. =)
…On Sun, 1 Apr 2018, 14:22 Paul Moore, ***@***.***> wrote:
@pradyunsg <https://github.com/pradyunsg> I'm not sure that
*unconditionally* having {sys.prefix}/pip.conf is right. Currently we
only do that if we're in a venv - doing so when not isn't a change that
anyone has requested as far as I know. Conda should be able to report
itself as a virtual environment, by setting sys.base_prefix (that's how
core Python expects virtual environments to report themselves as such).
This is not something I'm wiling to grant an exception for to put it in
10.0.0, as it's not a bug fix but a new feature. And regardless, I don't
see why we should change venv -> site. The feature is there for virtual
environments after all. (And I see conda environments as just another
approach to virtual environments, so I'm using the term generically here,
not limited to virtualenv/venv).
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#5060 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/ADH7SRgnZmxgaaVphT4QTmbC-bEYGwYBks5tkJVUgaJpZM4Sjm2w>
.
|
I've had a few of the Linux distros ask for something similiar over time, so I think it's something that folks want (to let them provide some default configuration for pip). I don't think that it needs to get added to 10.0 though, and I don't know that |
Unfortunately that's not really an accurate understanding of The key take away is virtualenv's link an external Python into their environment. Conda environments install a totally different Python into their environment. So the distinction of where other Python's may exist relative to the active |
OK, so conda environments are more like entire Python installations. OK. Pip currently doesn't have a per-installation config file. As @dstufft says, that's something we could add. |
Right. The Linux package manager analogue is a pretty good one. |
Has there been any progress on this? I'm in a related situation where my team has a separate (non-conda) installation of python, because we don't have root access on the machine, and would like a global pip config for our installation. I really expected it to look in {sys.prefix}/etc/pip.conf, or something. Is there a possibility of this being added? |
Not really. Looking at the discussion above again, ISTM the conclusion was that a per-installation configuration file has to be added, with its appropriate location, such that it's loaded just before venv configuration file. I guess what's left is figuring out the location and actually doing the implementation. |
Thanks @pradyunsg. So how do we go about deciding on the location? |
I want this badly enough to do the work :) (especially if/when I implement #6248, but right now for overriding the default index-url for a deployed environment - most of our deployments are full copies of Python that aren't tied to a system install at all but are wholly local to the directory they are in). I assume it should be checking one (or more) of the paths that get listed when you do
With a venv there's a bit more variety:
So I'm thinking one of |
FWIW here's the output from a Conda install on macOS (in the
Here's the output from the system Python on macOS.
Also here's the output from CentOS 7's system Python.
Thus far |
Another idea is to simply copy "whatever system is used for |
Ah missed those, sorry. There was a lot of noise in the |
What about |
Both of those also appear to be the same as |
That's what we do now. :) |
This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs. |
Related to issue ( conda-forge/conda-forge.github.io#518 ).
Noted that there was some special handling with virtualenv to figure out the
pip.conf
file to use related to that environment. Was wondering if the same thing might be possible for aconda
environment. Perhaps something like$CONDA_PREFIX/pip/pip.conf
or something similar for both Unix and Windows (guessing with.ini
as the extension). Though others may have thoughts on where this should live and how it should be named.cc @kalefranz @msarahan @pradyunsg
The text was updated successfully, but these errors were encountered: