8 ms·

'sudo pip install', really?

ihuman 13y ago
With some installations of python, you have to use sudo with pip in order for it to install anything system wide. (ex: OS X's preinstalled python).
- sitkack 13y ago
  Everyone should absolutely be running from a virtualenv. Never touch the system python. brew intall python /usr/local/bin/pip install --upgrade setuptools /usr/local/bin/pip install --upgrade pip /usr/local/bin/pip install --upgrade virtualenv /usr/local/bin/virtualenv --python=/usr/local/bin/python py.env And done. . ~/py.env/bin/activate pip install butterfly
  - deleted 13y ago
    [deleted]
  - derefr 13y ago
    Are virtualenvs (or Ruby bundles, or anything else equivalent) still relevant when using Docker containers? It seems to me that the proper thing to do, when you're making a container that runs a python app, is to install the app's dependencies to the container's global environment.
    - sitkack 13y ago
      I keep all of my systems the same between dev,test,prod so I still deploy into a virtualenv inside of containers. No reason to ever run something as root.
  - diminoten 13y ago
    I think homebrew handles this for you, which is great.
    - sitkack 13y ago
      Homebrew installs a specific pip, you still need to upgrade if you want to get the latest. Although it should be fairly up to date. Type `brew edit python` to peruse the recipe.
  - sashk 13y ago
    Using virtualenvwrapper is somewhat easier. pip install virtualenvwrapper source /usr/local/bin/virtualenvwrapper.sh mkvirtualenv -p /usr/local/bin/python venv pip install butterfly
  - naiquevin 13y ago
    > Everyone should absolutely be running from a virtualenv. Never touch the system python. Why exactly? I find it convenient to have some packages installed system wide so that they can be used by quickly loading up a python shell without having to activate a virtualenv first or if they need to be used outside any specific project eg. requests, nose, jedi, pyflakes, sphinx etc.
    - e12e 13y ago
      For most systems, if you have a "system python" you'll want the system package manager to manage that python (and python packages). Because breaking python can mean breaking the package manager. Personally I enjoy having a few bits installed under ~/opt/py-venv and simply add ~/opt/py-ven/bin to my path. It's usually no need to activate a venv to use it -- just call that venv/bin/{python|pip|hg|ipython|<whatever>}. In other words, whenever I "pip install something" that something is installed in my "default" virtualenv. And if/when things get out of hand/I need to upgrade to a new python -- I can just recreate the virtualenv and install whatever is needed.
    - sitkack 13y ago
      I have a default.env that is activated in my .profile so I can always just do a `pip install <package>` w/o having to touch the system python. The system python is for the system, not me.
- e12e 13y ago
  But how many people actually need system wide installs on OS X? That's only relevant if more than one uid needs access to the stuff. (One might argue that in case of one uid per mac, doing a system wide install isn't a problem -- but I'd counter with adding a new user and testing if whatever break-age is introduced with various local package installs is easier/quicker than having to reinstall os x...).
hcarvalhoalves 13y ago
It's a system-wide tool, there's nothing wrong with installing it with sudo pip install if you want it on your PATH.
- hdevalence 13y ago
  Yes, there is: system packages should by installed with the system's package manager. Otherwise, you have two systems managing the same set of files, causing tears and suffering. Packages not installed with the system's package manager should be installed elsewhere, e.g., a local install in a user's home directory, or (in the worst case) /usr/local or /opt.
  - hcarvalhoalves 13y ago
    You're assuming everybody follows the package manager religion. E.g., it would be fine doing this in OS X, and pip install will follow the best UNIXy practice.
  - lucian1900 13y ago
    pip installs in /usr/local, actually. It's not quite as bad as it looks.
    - hdevalence 13y ago
      Thanks for the correction.
- deleted 13y ago
  [deleted]
- paultag 13y ago
  I wrote about why this was a bad idea at: http://notes.pault.ag/debian-python/ http://notes.pault.ag/debian-python/ If you want a clear failure mode - if this installs requests globally, think about the chaos if you're on Debian stable, with 0.12.1, before the API break - after a pip install, you may end up with all the software on your system broken. When this happens, please don't file bugs with Debian. Thanks.

With some installations of python, you have to use sudo with pip in order for it to install anything system wide. (ex: OS X's preinstalled python).

sitkack 13y ago
Everyone should absolutely be running from a virtualenv. Never touch the system python. brew intall python /usr/local/bin/pip install --upgrade setuptools /usr/local/bin/pip install --upgrade pip /usr/local/bin/pip install --upgrade virtualenv /usr/local/bin/virtualenv --python=/usr/local/bin/python py.env And done. . ~/py.env/bin/activate pip install butterfly
- deleted 13y ago
  [deleted]
- derefr 13y ago
  Are virtualenvs (or Ruby bundles, or anything else equivalent) still relevant when using Docker containers? It seems to me that the proper thing to do, when you're making a container that runs a python app, is to install the app's dependencies to the container's global environment.
  - sitkack 13y ago
    I keep all of my systems the same between dev,test,prod so I still deploy into a virtualenv inside of containers. No reason to ever run something as root.
- diminoten 13y ago
  I think homebrew handles this for you, which is great.
  - sitkack 13y ago
    Homebrew installs a specific pip, you still need to upgrade if you want to get the latest. Although it should be fairly up to date. Type `brew edit python` to peruse the recipe.
- sashk 13y ago
  Using virtualenvwrapper is somewhat easier. pip install virtualenvwrapper source /usr/local/bin/virtualenvwrapper.sh mkvirtualenv -p /usr/local/bin/python venv pip install butterfly
- naiquevin 13y ago
  > Everyone should absolutely be running from a virtualenv. Never touch the system python. Why exactly? I find it convenient to have some packages installed system wide so that they can be used by quickly loading up a python shell without having to activate a virtualenv first or if they need to be used outside any specific project eg. requests, nose, jedi, pyflakes, sphinx etc.
  - e12e 13y ago
    For most systems, if you have a "system python" you'll want the system package manager to manage that python (and python packages). Because breaking python can mean breaking the package manager. Personally I enjoy having a few bits installed under ~/opt/py-venv and simply add ~/opt/py-ven/bin to my path. It's usually no need to activate a venv to use it -- just call that venv/bin/{python|pip|hg|ipython|<whatever>}. In other words, whenever I "pip install something" that something is installed in my "default" virtualenv. And if/when things get out of hand/I need to upgrade to a new python -- I can just recreate the virtualenv and install whatever is needed.
  - sitkack 13y ago
    I have a default.env that is activated in my .profile so I can always just do a `pip install <package>` w/o having to touch the system python. The system python is for the system, not me.
e12e 13y ago
But how many people actually need system wide installs on OS X? That's only relevant if more than one uid needs access to the stuff. (One might argue that in case of one uid per mac, doing a system wide install isn't a problem -- but I'd counter with adding a new user and testing if whatever break-age is introduced with various local package installs is easier/quicker than having to reinstall os x...).

hcarvalhoalves 13y ago

It's a system-wide tool, there's nothing wrong with installing it with sudo pip install if you want it on your PATH.

hdevalence 13y ago
Yes, there is: system packages should by installed with the system's package manager. Otherwise, you have two systems managing the same set of files, causing tears and suffering. Packages not installed with the system's package manager should be installed elsewhere, e.g., a local install in a user's home directory, or (in the worst case) /usr/local or /opt.
- hcarvalhoalves 13y ago
  You're assuming everybody follows the package manager religion. E.g., it would be fine doing this in OS X, and pip install will follow the best UNIXy practice.
- lucian1900 13y ago
  pip installs in /usr/local, actually. It's not quite as bad as it looks.
  - hdevalence 13y ago
    Thanks for the correction.
deleted 13y ago
[deleted]
paultag 13y ago
I wrote about why this was a bad idea at: http://notes.pault.ag/debian-python/ http://notes.pault.ag/debian-python/ If you want a clear failure mode - if this installs requests globally, think about the chaos if you're on Debian stable, with 0.12.1, before the API break - after a pip install, you may end up with all the software on your system broken. When this happens, please don't file bugs with Debian. Thanks.