
Tools of the Modern Python Hacker: Virtualenv, Fabric and Pip - iuguy
http://www.clemesha.org/blog/modern-python-hacker-tools-virtualenv-fabric-pip/
======
po
Also extremely useful: the hitchiker's guide to packaging.

<http://guide.python-distribute.org/>

Specifically this chart which shows the packaging roadmap:

[http://guide.python-
distribute.org/introduction.html#current...](http://guide.python-
distribute.org/introduction.html#current-state-of-packaging)

Too often when coming to a new language, it's hard to know what is old and
busted and what the future is.

~~~
geekfactor
"Too often when coming to a new language, it's hard to know what is old and
busted and what the future is."

This is too true. As a Python/Django newcomer that has been difficult.

Any perspectives on buildout and where it fits into the toolbox of the future?

I started using it after watching Jacob Kaplan-Moss' Django Deployment
Workshop ([1] -- highly recommended) and I like it, but I read about
virtualenv and pip much more often.

[1]
[http://python.mirocommunity.org/video/1689/pycon-2010-django...](http://python.mirocommunity.org/video/1689/pycon-2010-django-
deployment-w)

One thing I don't really get about Python deployment tools in general is the
idea of building eggs for everything, especially the parts of my own
applications that I will never redistribute. This seems to be emphasized with
all the tools.

~~~
po
I have never personally used buildout so I can't speak about it pro or con. It
always seemed a bit heavy handed to me but that's an uninformed opinion.

I also think the idea of packaging to egg files is somewhat unneeded. When I
use pip, I use cheeseshop for the more established frameworks I depend on
(Django, south, etc...) but I also use pip to pull directly from various git
repos.

When I package my own projects for use, I just drop a setup.py script in there
and then install from github using pip. Looking at my requirements.txt for my
main project, I have about 10 dependencies from cheeseshop and about 10
pulling from various git or bitbucket repos.

------
wgrover
This is an interesting take on using virtualenv: "In the last couple months I
have adopted the mindset that I will be mostly avoiding installing python
packages into the global 'site-packages', as I've found that it pays to manage
dependencies on more of a per-project basis, rather than globally installing,
and hoping all goes well."

This appeals to me, but are there good reasons for avoiding installing
packages to site-packages?

~~~
nailer
> This appeals to me, but are there good reasons for avoiding installing
> packages to site-packages?

There's a (pardon the language, but I don't know a better term) shitfight
between OS packages and Python packages for control of the global site
packages. Each will override the other.

My current setup, which works very well: use pip and virtualenv for
everything, leave the global site packages alone.

Everything you need to run Ubuntu this way can be achieved by:

apt-get install python-dev python-pip python-virtualenv virtualenvwrapper

Then mkvirtualenv, workon, and pip to your hearts content.

------
hartror
This post was my bible around September last year when we started doing a
major Django replacement of our code.

Combined with Django South it makes managing Django deployments a dream.

------
Ixiaus
In addition I also use virtualenv wrapper, pyflakes (for Emacs) and RopeMacs
(refactoring support).

------
rudd
I don't get why I'd want to use virtualenv if my production servers allow
global package installation. Ideally my Python deployment should be the only
thing running on the server, right? In that case, having a virtualenv seems
like overkill. And for local development, it's just a hassle to have to enter
the virtualenv every time I want to run the code, when I could just have the
needed packages installed globally.

------
koichi
When I saw this article, I thought it said "Monty Python," not "Modern
Python." Sad.

P.S. The parrot is not dead.

