pip.conf user = true conflicts with venv

[bernd-wechner]

Environment

• pip version: 20.2.3
• Python version: 3.8.5
• OS: Mint 20

Description

If pip.conf contains the user = true instruction then attempting to run pip in a venv results in:

ERROR: Can not perform a '--user' install. User site-packages are not visible in this virtualenv.

I could find not command line option that is the oppposite of user (i.e. disables the pip.conf set user = true and so had to edit pip.conf in order to install packages into a venv with pip.

Expected behavior

I'd expect not to have to edit pip.conf. If pip is run from within a venv and is aware it's in a venv how about silently ignoring the --user option? Or providing a command line option like --nouser to request it be ignored. That way Makefiles that implement venvs don't bomb on a local dev system which by default has user = true (which after all is recommended ... as we're working desktop environments that have loads of Python code and fiddling with system libs is not recommended, we leave that to Ubuntu or our distro to do, and use user = true to do our Python dev work)

How to Reproduce

Add user = true to pip.conf (in ~/.config/pip/pip.conf on Ubuntu systems) and then create and activate a venv and try to install package with pip.

Output

ERROR: Can not perform a '--user' install. User site-packages are not visible in this virtualenv.

[McSinyx]

FYI there's a --no-user flag. Whyever pip reads its real config in a virtual environment, I recall stumbling upon the discussion but cannot find it at the moment.

[uranusjr]

pip has real config in a virtual environment, at $(sys.prefix)/pip.conf. Having a user = false there would override the user configuration.

[uranusjr]

4141 has relevent discussions. (Probably not the one you’re thinking about, there are several threads on this.)

[bernd-wechner]

FYI there's a --no-user flag. Whyever pip reads its _real_ config in a _virtual_ environment, I recall stumbling upon the discussion but cannot find it at the moment.

Apparently not (anymore if it ever did).

pip has real config in a virtual environment, at $(sys.prefix)/pip.conf. Having a user = false there would override the user configuration.

That works though to be more precise it has to be:

[install]
user = false

and this rather esoteric feature could be more accessibly documented. But the fault there lies with venv not pip I suspect.

Creating a new venv should really just create this file given they are in conflict otherwise.

[McSinyx]

pip has real config in a virtual environment, at $(sys.prefix)/pip.conf

I suppose you meant virtual config :smile: (or config exclusively for the virtual environment, because my metaphor game suck :disappointed:). Also thanks for the pointer, it's not what I was looking for but interesting discussion indeed.

Apparently not (anymore if it ever did).

I'm pretty sure that it exists and I have suggested this in another thread not so long ago. Try pip install --no-user .... As you pointed out earlier, it's an install-specific option.

[pradyunsg]

FYI there's a --no-user flag.

This is not a supported end-user flag. Please don't use this.

[McSinyx]

Ah, thanks for the information. I was about to ask why but found GH-5116. I'll stop suggesting it to others but you can't stop me from using it myself :smiling_imp:

Edit: jokes aside, could you share which situation led you to have user = true in your pip.conf, @bernd-wechner? Such behavior has been default in Debian-based distros for as long as I can remember until upstream pip provides a smarter fallback mechanism, which essentially installs to users' site the majority of the times.

[bernd-wechner]

could you share which situation led you to have user = true in your pip.conf

it came recommended, more than once, in different contexts now. I do active Python development on an Ubuntu derived system (Mint) and the Desktop Environment and other system utilities are increasingly Python dependent.

I have broken elements of my desktop before by keeping system Python libs up to date. I've been warned NEVER To do sudo pip install. Without sodo pip fails unless you specify --user. Given this (common I'd have thought) use case making --user the default is sensible indeed.

The short answer is: I've been told in no uncertain terms NEVER to do sudo pip install and always pip install --user (or of course always use a venv).

[pfmoore]

Without sudo pip fails unless you specify --user

It shouldn't (assuming a recent pip). If site-packages isn't writeable, pip falls back to user site automatically. The recommendations you have seen are basically out of date and flawed, as you found out. (Never using sudo with pip is 100% correct advice, though 🙂) Unfortunately, it's hard to get rid of out of date information on the internet 🙁

[bernd-wechner]

Without sudo pip fails unless you specify --user

It shouldn't (assuming a recent pip). If site-packages isn't writeable, pip falls back to user site automatically. The recommendations you have seen are basically out of date and flawed, as you found out. (Never using sudo with pip is 100% correct advice, though slightly_smiling_face) Unfortunately, it's hard to get rid of out of date information on the internet slightly_frowning_face

Thanks for clarifying! pip evolves! And yes on-line advice can't always keep up with the sometimes impressive rate of improvement of FOSS! Alas. But it's a simple consequence of the FOSS boom methinks and how awesomely it marches forward.