Hacker News Reader

Comment by ngoldbaum | Hacker News Reader

'sudo pip install', really?

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

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.

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.

pip installs in /usr/local, actually. It's not quite as bad as it looks.

Thanks for the correction.

I wrote about why this was a bad idea at: 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.

> When this happens, please don't file bugs with Debian. Thanks.

We are all adults here. I believe the implications of using pip instead of apt on Debian are pretty clear for anyone using it. This is not an universal problem though.

No. It's not. If you saw the people filing the bugs, you wouldn't say this.

Unless you intend to (eventually) break your OS, system-wide packages should be installed with system-wide package managers. That is, dpkg/apt, rpm/yum, pacman, emerge or similar.

Failure to comply with this rule bites hard when you install some other package that uses Python and pulls dependency from OS repository that you had already installed from PyPI. That obviously fails due to files being already present (and probably from another egg's version) and you're probably already using this egg somewhere so you probably can't readily replace it. Manual clean-up of such mess isn't pretty nor fun.

So, if you want a non-project-bound package (like ipython), do so with `pip install --user`. Otherwise, virtualenv is the tool.

(Obviously, there are non-trivial exceptional cases where sudo pip is fine. I believe they're quite rare.)

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).

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

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.

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.

I think homebrew handles this for you, which is great.

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.

Using virtualenvwrapper is somewhat easier.

    pip install virtualenvwrapper
    source /usr/local/bin/virtualenvwrapper.sh
    mkvirtualenv -p /usr/local/bin/python venv
    pip install butterfly

> 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.

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.

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.

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...).

Reply on news.ycombinator.com