pip install numpy
# run into permissions issuessudo pip install numpy # or "sudo !!" for the power users ;)
~~~{% endraw %}
End of story, it works, it's what is written in the README so what's wrong with it?
You see, when you install a library through pip, you are executing {% raw %}`setup.py`{% endraw %} with root permissions. This file could harbor malicious code. You are also messing with the system libraries and that invariably leads to issues down the line.
Relevant XKCD (thx u/truh):
A much better and secure way would be:{% raw %}
~~~bash
pip install--user numpy # libs will be installed in ~/.local/lib
~~~{% endraw %}
This is better, and can be used for installing applications, but it doesn't solve the problem of having different versions needs for different python projects. Enter [pipenv](https://pipenv.readthedocs.io/en/latest/). {% raw %}`pipenv` is to python what `composer` is to PHP. It lets you **easily** install and use libraries per project. It's not the only tool allowing you to do that, but it's the one I use so it's the one I'm gonna present you. Example:
~~~bash
pipenv install numpy matplotlib pandas
# to start your program
pipenv run ./crunch-data.py
# to install libs from another machine, after a git pull:
pipenv sync
# to get a shell in the env (like `source myenv/bin/activate` for venv)
pipenv shell
This allows a very reproducible environment for your program, without resorting to Docker and without messing up user or system libraries. Save yourself from future bugs and start using pipenv, venv, conda or virtualenv right away! It's much better than {% raw %}`requirements.txt`{% endraw %} + pip. :)
Cheers,
~Nico
Fair enough. I do prefer the native package manager route when it's an option, but in those cases it's generally handled automatically as a dependency anyways. Really, 99.99% of all manual pip interactions should be happening in some sandbox env anyways. Regardless it's better practice to understand and respect root ops rather than fear them, because sometimes they are necessary.
We see it when we're installing an application that will be used by another user account, since ~/.local/lib (or the equivalent) isn't shared. This is pretty rare in a development environment, but it comes up frequently in an administered multi-user setup (say a shared workstation or batch cluster). Sometimes service accounts as well depending on what they're doing.
You can create a specific conda environment for each proyect, and even specify the conda channel from which it is installed.
I usually create an environment.yml file for this, so I only run
$ conda env create -f environment.yml
What about for pip install --upgrade pip
"ERROR: Could not install packages due to an EnvironmentError: [Errno 13] Permission denied: '/usr/bin/pip3'
How do you get pip into /usr/bin without running it privileged?
Here's a simple virtualenv manager that you can use to install Python apps in a safe way: github.com/dvershinin/pip-safe You can then just type pip-safe install <pypy-name> and it will take care of installing stuff and making it available on PATH. (you can use it instead of typing "pip install" and breaking things :)
Simple: install a real OS like GNU/Linux or Free/OpenBSD on your mac and you're good to go :p
No seriously macos is fucked up in various ways… But if you use pipenv or similar, you don't really have to worry about what is installed on the rest of the computer.
Built on Forem — the open source software that powers DEV and other inclusive communities.
