Add a mechanism to have a config file that can be overriden by user config

[dalebrydon]

What's the problem this feature will solve?

Right now the only way to specify a config file that a user can override is to use the global config file which a user needs root to create. This is difficult for shared systems where non-administrators provide Python support.

Describe the solution you'd like

I suggest adding an environment variable along the lines of PIP_DEFAULT_CONFIG_FILE which is loaded first and overriden by all other config files. The major downside to this approach is that it will be a little hard to document/could lead to confusing or messy documentation.

Alternative Solutions

It is pretty standard notion to have configs like global < user < project-level < env vars. pip somewhat breaks this with the way site and base work. The idea of site is that a virtualenv config is basically like the project-level config. Unfortunately, when pip is not being used in a virtual environment, this sort of breaks the above as then we have something that is like a global config overriding user configs. But, this behaviour is probably unchangeable at this point, otherwise a file location somewhere next to the Python install might be ideal. As it is, no other location make sense, which basically only leaves an environment variable.

Additional context

To clarify slightly the situation, we have a group of users who are not admins that manage our python installs where I work. These versions of python are installed in "non-standard" locations and are made available to users via environment modules. Additionally, we have internal PyPI mirrors and other config we'd like to make available to users as a default, but enable them to override. There's not really a mechanism to do this currently.

Note I'm happy to make a PR for this if there's support for adding this feature.

Code of Conduct

• I agree to follow the PSF Code of Conduct.

[uranusjr]

I don’t think this makes much sense, since the user can override that environment variable directly instead. Perhaps it is better to add a mechanism for a config file to “inherit” another config file.

[pradyunsg]

This is difficult for shared systems where non-administrators provide Python support.

We've added an interepreter level configuration option (#11487) for precisely this usecase.

[pradyunsg]

I think #9752 covers this.

[dalebrydon]

This is difficult for shared systems where non-administrators provide Python support.

We've added an interepreter level configuration option (#11487) for precisely this usecase.

But that mechanism overrides user config.

[dalebrydon]

I don’t think this makes much sense, since the user can override that environment variable directly instead. Perhaps it is better to add a mechanism for a config file to “inherit” another config file.

The idea of environment modules is that you do something like module load python3.10; python3 -m pip install blah. It wouldn't be very nice if switching versions of python also messed with pip config. That's an unnecessary intrusion into user space and will lead to confusion for the user (especially since user config isn't loaded at all if a PIP_CONFIG_FILE exists).

[pelson]

But that mechanism overrides user config.

Yes, you are right. The order of user config coming before base and site is unfortunate. At this point, I do not advocate for global or user config at all (the latter because of the precedence, the former because it is a sledgehammer).

The processing order is one of the reasons I wished to be able to control the processing order. I prototyped being able to configure the precedence, e.g.

config-precedence =
    base
    site
    user
    env_var

Which would do a first pass to compute the config-precedence, then a second pass (if necessary) to compute the final config. My implementation wasn't so complex, but it was possibly wrong (I think I found a problem with it at the time) and would introduce a whole new level of complexity to the config & docs... still, it would represent a good way to address this particular issue/need without breaking existing functionality.

---

As you pointed out in #11815 the PIP_CONFIG_FILE environment variable, despite what is said in the docs, is actually processed last. You could therefore set the environment variable to the user location if it is not set. module unload should do the right thing to restore the state afterwards.