3 ms·

Put more simply: never run `sudo pip install foo`. That's never expected to work, and it's a pity it doesn't just give a simple error "don't do that!" rather th

Put more simply: never run `sudo pip install foo`. That's never expected to work, and it's a pity it doesn't just give a simple error "don't do that!" rather than sometimes partially working. As you said, you should start a new environment instead and install whatever you like into that. For Python, that means using virtualenv or python -m venv. You can always use the --system-site-packages switch to get the best of both worlds: any apt install python3-foo packages show up in the virtual envioronment, but you can use pip to shadow them with newer versions if you wish.

rcxdude 6y ago
I basically don't let anything but the package manager touch /usr. Too many mysteriously issues in systems that had gotten screwed up. It's extremely rare that it's necessary for any project: if you need to build and install some other project you can generally just install in a directory dedicated to any single codebase you may be working (with appropriate PATH adjustments which can be sources from a shell script so they are isolated from the rest of the system). I really dislike tutorials and guides which encourage just blindly installing stuff into system managed areas but it's rife.
- zozbot234 6y ago
  > I basically don't let anything but the package manager touch /usr. That's the standard approach. Custom system-wide packages (as opposed to packages that are only installed for one user) should go in /usr/local/ or in a package-specific directory under /opt/.
  - quietbritishjim 6y ago
    The comment you're replying to is a bit ambiguous. Did they mean don't put anything directly in /usr (i.e. except /usr/local)? Or did they mean don't put anything anywhere under /usr? Both are consistent with my comment. Personally, I stopped using even /usr/local (or /opt) many years ago. If it's not managed by the operating system then it goes in my home directory (except a few things in /etc that have to go there).
    - rcxdude 6y ago
      Exactly. Stuff in /usr/local is very capable of messing with other parts of the system (plus it munges everything not package managed together, which is even worse).
kstrauser 6y ago
Pip has that feature now. Put this in your ~/.pip/pip.conf: [global] require-virtualenv = true and then you get errors like: $ pip install foo ERROR: Could not find an activated virtualenv (required).
- nemetroid 6y ago
  That's not exactly the same. I might be fine with installing Python packages with pip into my home directory, just not /usr.
  - kstrauser 6y ago
    My workflow's been to temporary disable that, do the stuff I need, then re-enable it. It's a bit clunky, but I don't install stuff outside a virtualenv frequently enough for it to be a major pain in the neck.
  - skrtskrt 6y ago
    Yeah I use pyenv + virtualenvwrapper and there are a few packages I am fine with having in the top-level pyenv version, rather than in any particular virtual environment: black, requests, click, etc.

rcxdude 6y ago

I basically don't let anything but the package manager touch /usr. Too many mysteriously issues in systems that had gotten screwed up. It's extremely rare that it's necessary for any project: if you need to build and install some other project you can generally just install in a directory dedicated to any single codebase you may be working (with appropriate PATH adjustments which can be sources from a shell script so they are isolated from the rest of the system). I really dislike tutorials and guides which encourage just blindly installing stuff into system managed areas but it's rife.

zozbot234 6y ago
> I basically don't let anything but the package manager touch /usr. That's the standard approach. Custom system-wide packages (as opposed to packages that are only installed for one user) should go in /usr/local/ or in a package-specific directory under /opt/.
- quietbritishjim 6y ago
  The comment you're replying to is a bit ambiguous. Did they mean don't put anything directly in /usr (i.e. except /usr/local)? Or did they mean don't put anything anywhere under /usr? Both are consistent with my comment. Personally, I stopped using even /usr/local (or /opt) many years ago. If it's not managed by the operating system then it goes in my home directory (except a few things in /etc that have to go there).
  - rcxdude 6y ago
    Exactly. Stuff in /usr/local is very capable of messing with other parts of the system (plus it munges everything not package managed together, which is even worse).

kstrauser 6y ago

Pip has that feature now. Put this in your ~/.pip/pip.conf: [global] require-virtualenv = true and then you get errors like: $ pip install foo ERROR: Could not find an activated virtualenv (required).

nemetroid 6y ago
That's not exactly the same. I might be fine with installing Python packages with pip into my home directory, just not /usr.
- kstrauser 6y ago
  My workflow's been to temporary disable that, do the stuff I need, then re-enable it. It's a bit clunky, but I don't install stuff outside a virtualenv frequently enough for it to be a major pain in the neck.
- skrtskrt 6y ago
  Yeah I use pyenv + virtualenvwrapper and there are a few packages I am fine with having in the top-level pyenv version, rather than in any particular virtual environment: black, requests, click, etc.