Providing pip configuration in `sys.base_prefix`

pip version

main

Python version

all

OS

all

Additional information

When a pip config is installed in an installation prefix $PREFIX/pip.conf, $PREFIX/bin/python -m pip correctly picks up the config. When one makes a virtual environment with $PREFIX/bin/python -m venv ./my-venv then ./my-venv/bin/pip does not pick up the config.

It is questionable if this is a bug or a feature request, but essentially, I believe that pip should be looking in sys.base_prefix as well as sys.prefix for a config file.

Description

No response

Expected behavior

No response

How to Reproduce

Starting with a non-virtual environment (e.g. a conda environment):

$ touch ./env/pip.conf
$ pip config debug
env_var:
env:
global:
  /etc/xdg/xdg-ubuntu/pip/pip.conf, exists: False
  /etc/xdg/pip/pip.conf, exists: False
  /etc/pip.conf, exists: False
site:
  /media/important/github/pypa/pip/env/pip.conf, exists: True
user:
  /home/pelson/.pip/pip.conf, exists: False
  /home/pelson/.config/pip/pip.conf, exists: False

$ python -m venv ./venv

## BEWARE THAT YOUR VENV HAS THE BUNDLED PIP, SO INSTALL A NEWER PIP FOR DEBUGGING
$ ./venv/bin/pip install -e /path/to/pip/repo

$ ./venv/bin/pip config debug
env_var:
env:
global:
  /etc/xdg/xdg-ubuntu/pip/pip.conf, exists: False
  /etc/xdg/pip/pip.conf, exists: False
  /etc/pip.conf, exists: False
site:
  /media/important/github/pypa/pip/venv/pip.conf, exists: False
user:
  /home/pelson/.pip/pip.conf, exists: False
  /home/pelson/.config/pip/pip.conf, exists: False

What I want to see for a venv is that the base_prefix is searched as well as the prefix.

Output

No response

Code of Conduct

• I agree to follow the PSF Code of Conduct

[layday]

If we can step away from discussing the implementation for a minute, what’s not been made clear through the course of this conversation is that this change would only be applicable to Conda environments, because Conda apparently mangles the value of sys.base_prefix of a Python installed in a Conda environment. This means that you can keep a development environment-local pip configuration in the “global” Python prefix, a peculiarity only found in Conda environments.

[pradyunsg]

I’ve retitled this issue, to better reflect what is being asked for.

As useful context/background, I wrote pip config and wrote/refactored most of the configuration logic a few years ago (stating this to establish I’m reasonably familiar with it, and not to imply that I somehow “own” this piece within pip or have any sort of authority over this beyond what my fellow maintainers do).

I think the rationale provided here for adding a new level is reasonable, and I’m fine with adding an additional config file at base_prefix.

I will say this: this is a weird organisational situation you’re in, where you can’t/don’t want to influence the global configuration (i.e. it’s fine to have pip reach out to whatever is configured there, or the default PyPI) and you don’t trust/want your users to configure their tools to work correctly (i.e. by documenting/educating about a standard config file for the use case). I’m not sure what pieces are specific choices by you vs being forced upon you. 😃

Coming back: I don’t think an additional config file layer is particularly that expensive for us in terms of the code + maintenance, and it feels like the right level of abstraction to solve this particular class of organisational/usage-pattern problems at – the main concern I have is around (a) documenting this clearly+completely, and (b) a clean migration to this. Since it’s effectively a new feature, (b) is less of a concern. (a) is something that will end up needing to be a part of the PR adding this. I’ll guess that this is something that’s mostly useful for organisational users, where there’s some shared configuration for Python development that only applies to a subset of users (likely the package index?).

I’d be happy to review and (assuming no other maintainers are strongly opposed) merge a PR for this.

To err on the side of overcommunicating… I’ll explicitly state that I’m not promising that I’d take a look at such a PR quickly though – trying to juggle quite a few things at the moment. I also haven’t been looking at this thread closely due to limited bandwidth on my end. I’ve quickly skimmed through the initial bits of this thread and the most recent comments (sorry, there’s way too much text here and I have limited mental energy right now) and that’s the context I had when I wrote this. Sorry if I’ve missed some nuances/points that have been brought up already. 🙈