Hacker News Reader

Comment by sitkack | Hacker News Reader

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

View on HN

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.

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.

Reply on news.ycombinator.com