Pip vs Pacman - How to pack Python packages 📦

[naveen521kk]

Forked from #7569 (comment)

• How to pack Python Package? Is it good using Pip? Or Pacman should be used?
• Should new package be created for projects in pip? If yes, is it worth updating these many things? What about the Python Projects which can be literally run on any system(so called pure python projects), should that be packed using Pacman?
• Should we patch pip so that it warns that,

  There exists a *package* called [...] in msys2-mingw repository, it is recommended to install using that
  

  Or is there a better solution than that? If we are doing this, What about Python's venv? Should we patch that also?
• Is it worth suggesting the upstream to create new ABI tags for msys2-mingw python?
• There are quite a few Python project which which comes with vendored dependencies. What to do about that? Should we follow what Arch do?(Remove all vendored dependencies). See Wrong dependencies for python-pip #7580
• How about automatically maintaining all python-* package or rather all packages?
• If we concentrated more on python packages, what will happen to other old packages which we aren't sure whether they build or work?

@umarcor quoted a way in which Python package a in which packages can be split from #7569 (comment)

I would classify all existing Python packages in three groups:

1. Packages that need to be installed as pacman packages. For example, most SciPy packages need to be system packages because they rely on so many lower level C/Fortran frameworks/libraries. In these cases, I'd call it almost pointless to try handling them as pip packages.
2. Packages that don't need to be installed as pacman packages, but which are dependencies of other pacman packages. These don't have any dependency on C/C++, so the only reason for them to be pacman packages is allowing the dependency resolution algorithms to work.
3. Packages that can be distributed/installed in any way (pacman, git, pip, etc.) because they are leaf packages which don't have any dependency on C/C++ neither a strong dependency on the versions of Python packages distributed through pacman (I'm thinking about projects using e.g. pytest, which don't care much about the version of it).

• Is it worth doing so? If doing so where to maintain the list? Who would would be maintaining it? Isn't that a additional burden?

[mingwandroid]

To me, all 3 of these are best served as pacman packages! I think @umarcor has a distinction in mind regarding C and C++ as being somehow more systemic than Python packages and therefore those ones are more appropriate, but to me this distinction is artificial. Pacman (and any reasonable package manager) deals with files, the contents of those are of little or no concern to the installing tool. Why would Python be given special consideration here? It's not orthogonal.

Skipping 1 (as we all agree on that though the wording of it is the point of creation of my artificial distinctions), let's take each in turn.

2. Can we list what the downsides would be to having them as pacman packages as well as the upsides, and also what the alternatives are? Can we also agree that these dependencies should, whenever possible, be installed automatically? They are not, after all optional and we should not put burden on our users to issue extra commands beyond pacman -S IMHO.

3. Well, any package can be distributed in any way, more or less. A zip file, a tarball, a self extracting thing, whatever. The definition of a leaf package is not fixed. I could create a tool that I later split into a tool and a lib. I could do this without renaming my project. Other projects could start using my lib and all of a sudden my package is no longer leaf. If we'd just stuck with pacman (as we always have in the past) then we don't need to think about any of this.

Honestly, I just think we're making problems for ourselves with these proposals but I am happy to discuss it in depth with y'all.

Cheers.

[1480c1]

2 Can we list what the downsides would be to having them as pacman packages as well as the upsides, and also what the alternatives are? Can we also agree that these dependencies should, whenever possible, be installed automatically? They are not, after all optional and we should not put burden on our users to issue extra commands beyond pacman -S IMHO.

Personally, the only reasons why I would use pip over installing a distro provided package would be that usually the pip provided ones are newer and I might require the newer one or pip might have a package not available in apt or yum. However, for me this is usually limited to just meson and ninja-build. In the case of msys2, I would say that reason is nulled since lazka and co has been very good at keeping up with the latest packages for meson, etc so I don't need to install pip at all right now.

[umarcor]

I think @umarcor has a distinction in mind regarding C and C++ as being somehow more systemic than Python packages and therefore those ones are more appropriate, but to me this distinction is artificial.

The distinction is not mine! It's called "compiled languages vs interpreted languages"! Precisely:

https://en.wikipedia.org/wiki/Interpreted_language
Features that are often easier to implement in interpreters than in compilers include:

• platform independence

You might consider the distinction negligible because you might expect pacman to handle any tool which will ever be used on MSYS2. That's a legit position. However, please do not play straw arguments, portraying a very obvious point as an idea of mine.

Why would Python be given special consideration here? It's not orthogonal.

Please, try to rewrite your comment from a pythonist's perspective. You'll find that exactly the same arguments apply the other way round. Therefore, unfortunately, those points are useless in the balance. Let me be more explicit: why would maintainers of Python packages learn how your system and your package manager works if they already have a "reasonable" manager to deal with files, versions, dependencies, etc. which works on "any" platform? Why would MSYS be given special consideration here? Furthermore, why would MSYS2 be considered relevant at all if Microsoft doesn't like it and they are making their best for users to pick other products? Note that I'm playing the very bad guy here. That's something I've been told so many times when suggesting open source projects that MSYS2 was probably the best option for them on Windows. I've also seen many suggestions from Microsoft employees about not using MSYS2.

If you don't want any package manager other than pacman and they don't want any package manager other than theirs, we are all pretty f****d up. Neither your ideal view nor theirs did work so far and won't work in the near future (regardless of all parties making their best for it to come true, disregarding others). That's why we are having this dialogue.

Moreover, this issue is about Python/pip. However, the same arguments would apply to js/npm/yarn or go or rust or haskell or.... All those package managers could ""potentially"" be unnecessary because "pacman can already deal with files and dependencies". Should MSYS2 maintainers take care of merging all those package databases into pacman just because "pacman can do it"? Note that this is obviously a reductio ad absurdum to argue why multiple package managers need to coexist in RealWorld.

Can we list what the downsides would be to having them as pacman packages as well as the upsides, and also what the alternatives are?

The single relevant downside of having all Python packages as pacman packages was already explained: MSYS2 as a project does not currently have the capacity to maintain that. I don't think it's worth considering the advantages of such a fictional situation. We should first discuss how to make MSYS2's flow fast enough so it can handle several additional hundreds/thousands of packages, while reducing the reaction time to 24h.

Can we also agree that these dependencies should, whenever possible, be installed automatically? They are not, after all optional and we should not put burden on our users to issue extra commands beyond pacman -S IMHO.

I do like this wording a lot! I believe we all agree that these dependencies should, whenever possible, be installed automatically. The discussion is which needs to be the entrypoint to trigger it: should it be pacman only? pip only? or any of them (up to the user)?

Coming back to a previous comment of mine in #7569:

Since there is no yaourt/yay equivalent in MSYS2 AFAIAA, I find of utmost importance to properly ponderate the effort of all the parties involved in the process.

Given Ray's preference towards managing everything through pacman, and only pacman, I honeslty think that the best solution would be to have a yaourt/yay equivalent in MSYS2. Moreover, I believe it should be implemented as a patch to pacman. There is a very relevant distinction between packages in MSYS2 and the ones from Arch Linux: here "standard" prefixes exist (mingw-w64-*, clang-*, see msys2/MSYS2-packages#2289). Therefore, all pip packages might be aliased as py-pip-PACKAGENAME. pacman/yaourt/yay would parse that and use PyPI as a source repository. As @naveen521kk explained, PyPI can host pre-built wheels, but it can also host source tarballs. Therefore, it's not different from git, mercurial, or plain URLs, from pacman's perspective. Furthermore, unless patching is required, exactly the same PKGBUILD template can be used for any Python package.

The obvious benefit of that is that any published PIP package would automatically be a package manageable by pacman, without maintainers of MSYS2 duplicating the recipes and manually updating all of them. The downsides are that some would need to be built at installation time (requiring additional dependencies for installation), and the registry of MSYS2 would need to sync with the list of available PyPI projects.

Honestly, since *-python-pip exists on MSYS2 and it works ok for many source packages or for interpreted only packages, I don't see the need for reimplementing in pacman all the logic for interacting with PyPI. I would make pacman call PIP internally. However, my guess is it'd be considered not as purist as it should. Funnily and sadly, @naveen521kk reaction to the opposite proposal (letting pip understand pacman) was "that would mean that we should completely rewrite pip and IMO shouldn't happen", without further clarification. We will hardly get nowhere if parties expect others to adapt to their tools only.

On the other hand, the idea of adding aliases to pacman can be applied to other features. For example, pacman -S staging-w64-* might allow users to install packages available in the autobuilder but not signed/uploaded yet. This would significantly reduce the lag between packages being updated and them being available as canonical pacman packages. It would apply to Python packages but also to any package in MSYS2. Then, we might think about autogenerating and testing hundreds of PKGBUILD recipes for PIP packages automatically.

Well, any package can be distributed in any way, more or less. A zip file, a tarball, a self extracting thing, whatever. The definition of a leaf package is not fixed. I could create a tool that I later split into a tool and a lib. I could do this without renaming my project. Other projects could start using my lib and all of a sudden my package is no longer leaf. If we'd just stuck with pacman (as we always have in the past) then we don't need to think about any of this.

I'm sorry, but this is a no argument. Yes, all projects start non-packaged and at some point someone prefers to create a recipe for some package manager. Sometimes projects split, other times projects merge, or people start building on top of a previously isolated project. Splitting or merging projects requires modifying recipes. That has nothing to do with any specific manager, nor with being a leaf.

A leaf package is one that does not have another known package which depends on it. That is, the nodes in DAG which have arrows in a single direction (in/out depending on the convention about edges). It's a mathematical definition, so it's fixed. At a given point in time, you can analyse the MSYS2 repo and get an exact list of leaf packages. Moreover, that's implicitly done by the autobuilder every few hours.

The point here is that hundreds/thousands of developers all over the world decided that writing PKGBUILD recipes for their Python packages was not worth the effort, or they just ignore that they can do that. At the same time, thousands/millions of users can already use those projects on MSYS2 without using pacman. You are saying that's wrong, and they should all be writing PKGBUILD recipes for MSYS2 instead. However, you are missing the most relevant point: who is going to write and maintain those? What added value are you providing to convince them about it apart from (I picked pacman and it's the best solution)? Again, I'm being very cheeky here, because that's what we get when we move this discussion to RealWorld.

Personally, the only reasons why I would use pip over installing a distro provided package would be that usually the pip provided ones are newer and I might require the newer one or pip might have a package not available in apt or yum.

Exactly this. The more of niche, the less likely that MSYS2 experts will exist for writing and maintaining recipes. meson and ninja are some of the most loved packages by MSYS2 maintainers for very obvious and justified reasons (potentially the majority of builds will depend on them).

[1480c1]

Is it worth suggesting the upstream to create new ABI tags for msys2-mingw python?

It might be better to ask for upstream support or at least a promise of some kind that they would accept patches or help to add some way to be able to use a non-standard platform ( in the same vein as musl based pip packages instead of glibc ones). However, looking at it from their side, I think adding support for other configurations might be too much effort and work to have as a first-class config, especially if they have to consider testing and whatnot

[mingwandroid]

Go ahead and ask. From experience with CPython this is how i think that would go:

They'll tell you to do the work and submit a PR. You'll do that and then no one will review it, ever. There simply isn't the bandwidth. The Windows python maintainer works for MS and could do without having to support another compiler.

But try if you like. I decided not to because i didn't / do not see the need for wheels on msys2 and thought it would never get accepted anyway.

[mingwandroid]

If you want to see some evidence of why I think this about CPython, please have a look at this PR:

python/cpython#19501

Nearly 1 year old, completely trivial, verified to work, been applied in Anaconda Python since April last year.

Without it, if you have 64+ threads and use multiprocessing, things will break, badly.

So if anyone really wanted to work with CPython upstream to get a wheel ABI string for MSYS2/mingw-w64 python that would involve by necessity, upstreaming all of our patches.

Good luck! Not a job I'll be taking on any time soon, but that's OK for me since I don't want to use wheels or pip.

[umarcor]

Should we patch pip so that it warns that,
There exists a package called [...] in msys2-mingw repository, it is recommended to install using that
Or is there a better solution than that? If we are doing this, What about Python's venv? Should we patch that also?

Note that my proposal was mainly meant for warning users about packages which are known to be broken if installed through pip. When a users tries to use a package through pip and it crashes, there are several options:

1. The package is already available through pacman.
2. The package is not available through pacman yet.

In both cases it is desirable for pip to not install the package, unless the user confirms explicitly. In the second case, there are two possible solutions:

1. The package is added as a PKGBUILD recipe, including patches.
2. The package is patched/fixed upstream, so newer releases work through pip.

Both of them require similar expertise, since patches are the same but applied in different locations. Therefore, it might take a while until any of them is done. In many cases (smaller less used projects), it takes years or forever. It's for those case that I recommend having a list of "known to fail pip packages" rather than having issues or it being undocumented.

Is it worth doing so? If doing so where to maintain the list? Who would would be maintaining it? Isn't that a additional burden?

I think that closing a failure/crash report by adding a package to a list is easier than diving into the project and patching it.

[Alexpux]

When we start to port Python for Mingw years ago we try to discuss with Python developers about adding Mingw as official platform. But they don't want to do it. There are was plenity of patches on Python bug tracker about Mingw support - no one was merged.

• Mingw Python is not official platform so no one Python developer even support it and provide support in its packages.
• Mingw Python library not compatible with MSVC one, so every CPython extension must be recompiled with our toolchain.
• Mingw Python have different folders structure (Linux based) than MSVC.

All of the above affects our decision to rebuild packages rather than use Pip.
MSYS2 filesystem structure must be fully controlled by pacman to resolve files conflicts. Time to time users open issues about conflicts files because in the past they install thirdparty packages by PIP.
Using pacman allow us to search files or info throw its database so there will be no universe procedure if we will use different packages for different things.

[umarcor]

Can you maintainers agree on adding a section about that in https://www.msys2.org/docs/package-management/ ?

[mingwandroid]

Sure!

[mingwandroid]

BTW, if you really want to use pip on Python on Windows, I know of two reasonable options, official releases and those from Anaconda, Inc.

I don't want usage or promotion of pip damaging MSYS2's reputation which I am very sure it would do in its current state. If you are so motivated to fix that then fantastic but it will take years of effort to get our patches upstreamed I believe. Heck I'm trying for 1 year to get a single character change upstreamed, and one that makes CPython look bad on high end Windows machines at that! And I am friendly with the CPython Windows maintainer!

[umarcor]

I don't want usage or promotion of pip damaging MSYS2's reputation which I am very sure it would do in its current state.

Ray, it's happening. I want to document what's happening precisely so that people don't think that "using Python on MSYS2 is broken". The dialogue here is one of the many problems. To start with, many users install pacman -S python, and then things go badly because packages are not found. Or they use specific features which work with that python, but not when they try it in CI with mingw-w64-*-python. This might sound stupid for an MSYS2 maintainer, but that's the first experience of many users who are ignorant about packaging details on MSYS2. Guidelines for Python users can avoid it, and that's easier to achieve than any technical contribution to CPython.

[mingwandroid]

Great stuff, and thank you very much for your work and for helping work through this to an agreeable conclusion!

[mingwandroid]

All this stuff about pip is to completely moot until it works, and works properly and that does involve upstream PyPI support.

We should not be promoting or building tools with sharp edges. That's going back to the bad old days.

@1480c1 I do not believe for one second that in general MS dislikes MSYS2. There'd be no Git for Windows without it, for example. And that's maintained by an MS employee.

[1480c1]

@1480c1 I do not believe for one second that in general MS dislikes MSYS2. There'd be no Git for Windows without it, for example. And that's maintained by an MS employee.

although I'm not sure where this comes from, I definitely don't think MS dislikes MS, or at least if they do, they understand its importance and popularity as a tool itself and as a dependency, ranging from directly with git for windows to indirectly with compiling popular autotools based or any other shell-based configure scripts such as FFmpeg in native windows without resorting to cross-compiling from linux or wsl. This is excluding cygwin since usually, people compiling with cygwin are compiling for cygwin as a target rather than mingw-w64.

[mingwandroid]

If you don't want any package manager other than pacman and they don't want any package manager other than theirs, we are all pretty f****d up. Neither your ideal view nor theirs did work so far and won't work in the near future (regardless of all parties making their best for it to come true, disregarding others). That's why we are having this dialogue.

Packaging all the things that their users want as 'native' packages seems to be working just fine for ArchLinux, debian and every other distro I've seen.

pip is liked by Pythonistas. I'm heavily involved in Python, but I am not blind to its warts. Far from it, I know them all too well. Pacman is far better than pip IMHO, as is conda. The technical facts are just that. We cannot brush them under the carpet.

That there are many pip packages we don't provide so far isn't of much relevance AFAICT. It is far from difficult to add any given Python package to MSYS2 and it is the right way to do it. If we, or some of our users want a package, they will add it.

If making PKGBUILDs is burdonsome (I cannot agree with that personally) then add some tooling around it. On conda we have conda skeleton pypi <project>. That will create a (fully working) set of recipes for all missing transitive dependencies for a PyPI package. Those packages can then be built with a single command (conda build <package>) and it rarely goes wrong.

[mingwandroid]

You are double betting on the idea that it will work. Unfortunately, we will have to wait until MSYS2 has the relevance and resources (technical and human) of the projects you compare it with. That might take years, decades, or forever. Until then, the system is broken and AFAIAA it's not explined anywhere how broken it is.

It already has the relevance and resources IMHO, perhaps not at the same scale of a debian or ArchLinux, but I don't see how us being smaller makes the comparison invalid in any way.

[umarcor]

So you are happy to ignore that anything that needs compilation is just broken.

Not at all! I'm happy to let users of MSYS2 know which are currently broken and which are not. Your point is that PIP is completely broken, which is not true because many users do actually use it without issues. Others claim that all packages can potentially be handled by PIP, which is neither true because many packages will never be patched. I'd like users to get accurate descriptions and not the ideal views of the maintainer/contributor the talk to. For instance:

"ATTENTION: Using PIP packages is discouraged becasuse (...). Most (if not all) wheels packages will likely crash. If you ever use PIP packages, make sure to do it locally and/or inside an venv, because conflicts with system packages might arise."

Sorry that's unacceptable to me. If we are saying "go ahead and use pip" then pip needs to work and it needs to work correctly. For that we need to upstream all of our patches to CPython.

Since that's an "all or nothing" point of view, I already said that focusing on creating tooling around is a need.

If you want to get involved in that then please go ahead.

I'm willing to help document what is known to work and what is known to fail, so users can faster understand the details and non-standard problems on MSYS2. As I already said, I don't have any interest in supporting distributing pre-built packages/assets through PIP. I wish wheels were just removed from PIP (there's Conda for that).

if it works correctly and does what you want

So far, it works correctly and it does what I want it to do. I can use all the Python only packages through PIP. I can install all others through pacman. When a Python package needs a shared library, I create a PKGBUILD recipe for the library/assets only and distribute the scripts through PIP. That reduces the number/length of PKGBUILDs recipes to be maintained and the interactions with MSYS2 maintainers, while providing a faster delivery of scripts. Moreover, that's coherent with what other contributors have been doing.

That's why I find this dialogue so misleading/conflicting and I'm pushing to have it clarified and written down!

It already has the relevance and resources IMHO, perhaps not at the same scale of a debian or ArchLinux, but I don't see how us being smaller makes the comparison invalid in any way.

Releases in Debian might take years, so not comparable. Arch is a rolling release, and it has AUR precisely for avoiding the lag due to maintainers checking/signing/reviewing. As said, Arch would be a good comparison if MSYS2 had a yaourt/yay alike, and/or if staging packages could be installed through pacman.

[mingwandroid]

Releases in Debian might take years, so not comparable

Why? Just because you can highlight a point of difference it doesn't invalidate the comparison. Debian and Ubuntu use apt to install their system python packages. That is the thing that I am stating is the same. How does this release time-lag play into this (at all?)

[mingwandroid]

Simply, the debian maintainers also realised that pip is problematic vis-a-vis system package management and therefore they avoid it.

[umarcor]

Releases in Debian might take years, so not comparable

Why? Just because you can highlight a point of difference it doesn't invalidate the comparison. Debian and Ubuntu use apt to install their system python packages. That is the thing that I am stating is the same. How does this release time-lag play into this (at all?)

The only motivation for using PIP on Debian or MSYS2 is that writing and updating system packages can take very long since the developers publish a release. On Debian, system packages taking very long to be added/updated upstream is the natural thing, because it's known for being the most slow but most robust of the distros. Therefore, users do already know that they might need to find workarounds for installing latest versions. Conversely, on MSYS2, time constraints are so tight because it is presented as a rolling release for developers and using workarounds is undesired.

You are looking at it from a system maintainer's perspective. Please, try to put that hat aside just for enriching the discussion. Your point about Debian and Arch maintainers preferring system packages only is clear; we do agree on that. I'm trying to share ideas about how the world looks like from the users' perspective.

[Alexpux]

@umarcor I don't understand the problem of this discussion completely. Sorry for my English.

Nobody forbids using PIP. Every user can decide to use it or not use.
MSYS2 package management are constructed around pacman.
You can just install python package and then all other python packages install via PIP, but in this case you must solve all issues yourself.

[umarcor]

@Alexpux I was waiting/hoping some maintainer to say exactly what you did:

MSYS2 package management are constructed around pacman.
You can just install python package and then all other python packages instal via PIP, but in this case you must solve all issues yourself.

Now, I will write something to be added to the docs.

[mingwandroid]

Well, I believe I've been saying that from the very start.

[mingwandroid]

Funny thing is, we have some of the exact same issues with pip on conda

pip will happily overwrite files that conda wants to manage. We can and do use pip (from source-dists only!) when building our packages, but we never recommend inter-operation between the two in a single conda environment, we recommend pip users to only install to their user site-packages directory and to let conda manage the conda installation entirely.

It really is the honey-badger of python packaging to me.

[naveen521kk]

As for whether there is or not, I cannot remember, probably?!

It's there but in a weird location(unexpected) though.

$ python -m site --user-site
C:\Users\<User>/.local/lib/python3.8/site-packages

so that means user site-packages is enabled and is present in that directory. Also, things in user-site packages takes precedence over the one in system, so user wouldn't know that this is happening. So, IMO, 👍 for making pip to install in user site-packages for ever, and not touch the stuff which pacman is intersted in.

[naveen521kk]

Or better is it possible to make the things which pacman is intersted in write-proof by pip? If that happens, pip will by default fall back to user site-packages.

[danyeaw]

You can export PIP_REQUIRE_VIRTUALENV=1, then nothing installed by pip can overwrite pacman installed packages.

[naveen521kk]

@danyeaw then is it ok to add it to the profile of the user by default when installing python?

[danyeaw]

I would be good with that. We could document how to override the setting if really required for some reason.

[naveen521kk]

I think upstream fixing pypa/pip#5605 will fix all the issues discussed here.

[mingwandroid]

I disagree. Its an improvement for sure but pacman will then refuse to overwrite pip installed things. I strongly prefer we stop the files from being in the same place.

[naveen521kk]

I strongly prefer we stop the files from being in the same place.

👍 for this, actually. Either patching pip or setting an env var as @danyeaw told will help.

[naveen521kk]

Now, for some reason, I went to this page https://docs.brew.sh/Python-for-Formula-Authors#installing-1 and that seems to a rather best solution for me at least.
What that is we should move the package installed by pacman elsewhere and create a .pth file to make those visible to python, and finally, the problem is solved. Pip can do whatever it wants with the default installation location. What do you think @lazka?

More information about this is available to docs: https://docs.python.org/3/library/site.html#module-site

[naveen521kk]

I started thinking about what should be done so that this works.

First I thought a .pth file say pacman_installed.pth is placed in /mingw64/lib/python3.8, when installing Python itself. The contents of the file should be where Pacman should be installing python packages, say /mingw64/lib/pacman-python3.8 (suggest me a good name?)(should be absolute though), that can be accomplished by adding the following arguments to python setup.py install command

PYVERSION_TWO=$(python -c "import sys; print(f'{sys.version_info.major}.{sys.version_info.minor}')")
MSYS2_ARG_CONV_EXCL="--prefix=;--install-scripts=;--install-platlib=;--install-lib=" \
${MINGW_PREFIX}/bin/python setup.py install --prefix=${MINGW_PREFIX}  \
    --root="${pkgdir}" --optimize=1 --skip-build \
    --install-lib="${MINGW_PREFIX}/lib/pacman-python${PYVERSION_TWO}/" \
    --install-scripts="${MINGW_PREFIX}/bin"

and doing like this all the python package will simply solve this issue. Meanwhile, this needn't be done all at a stretch as it will not break anything( I think ), and could essentially solve this problem. Thoughts?

[lazka]

I'm not a fan of this since we are already different in many ways compared to a "supported" Python environment. And this adds one more difference on top.

Also this means a lot of work and convincing various build systems to install to non-default directories.

[naveen521kk]

Now I think let those standard tools install it in the same place. I just need to patch to pip to install it else where, but within MINGW_PREFIX, not outside of it, atleast it will reduce confusion.

[lazka]

I've opened a PR for making pip default to --user installs by default, copied from Debian: #7911