$ sudo easy_install <package>

and down that road lies madness.

The problem is that easy_install by default drops things into /usr/lib/pythonX.Y, which messes up the packaging system, and also interacts badly with other software needing conflicting versions of the same libraries installed. Yes, it happens all the time when you’re developing: often different Plone or Zope versions depend on different libraries, or you install twisted-based applications via the package manager that use library versions that conflict with development, or all kind of other ugly stuff (DLL hell, anyone?).

Another problem is that your users are suddenly unable to work except from the box where they installed the software, so if you have a visiting geek from elsewhere using that computer, you need to get creative with ssh to get work done. And you know the visitor will dutifully turn off the computer when she leaves, in the middle of your work. Or that reinstalling the machine due to a dead disk now involves more than the work of the ad-hoc sysadmin; it means lost productivity for the developer, too.

One workaround is to download Python and set it up in your home, so you have your own python, your own libraries, everything securely installed in a project-specific location. This is the other end of the scale, and while it does work, it’s a terrible pain to keep everything updated (gentoo, anyone?).

The right way to do it, in that it balances the need for autonomy with the need for expediency, is to use virtualenv to provide for having customized, lightweight Python installations without having to grow your own. One thing that I find funny (in the what are they thinking?!? kind of way) is that virtualenv’s installations instructions are… yes, you guessed it:

$ sudo easy_install virtualenv

Fortunately you can download virtualenv and use it directly,

$ cd /tmp/
$ wget http://pypi.python.org/packages/source/v/virtualenv/virtualenv-1.1.tar.gz
$ echo '8931b66dbb799120583dd107aab2fa89  virtualenv-1.1.tar.gz' | md5sum --check
virtualenv-1.1.tar.gz: OK
$ tar xzf virtualenv-1.0.tar.gz
$ cd virtualenv-1.1
$ python virtualenv.py ~/src/project/env/
New python executable in .../env/bin/python
Installing setuptools.............done.
$ cd ~/src/project/env/
$ . bin/activate

The last two lines are all it takes now to be able to do

(env)$ easy_install package

and have package installed inside your project’s hierarchy. Also, python is now the python in that hierarchy, and all your libraries come from there by default, so you can override the system-installed ones very easily. With this, the buildout starts to make a lot more sense in a multiuser context. In fact, it’s such a powerful combination I can’t think of any reason to carry on doing things the old way.

Gracias a Jon Stahl por el link.

Así que si en el futuo cercano, cuando haya salido 2.6, se les muere el perro, es culpa de Facundo, por invitarme :).

Así que si sos fanboy de Django, TurboGears, Pylons, web.py, Zope 3, Grok, Plone, o cualquiera de los frameworks para hacer aplicaciones web en python, lo único que tenés que hacer para el 15 de febrero es hacer esta aplicación. No trabajar, no estudiar, no comer, no dormir. Un blog. Multiusuario, extensible, con comentarios, tags (categorías), y temas (emm… que le puedas cambiar la pinta sin saber programar). Y que las URLs sean bonitas, porque estamos en el siglo XXI.

La idea es poder mostrar lo mejor de cada framework, así que las presentaciones pueden ser individuales, grupales, o colectivas; pueden usar todo lo que usarían para un proyecto “real” (es decir, lo que fuera parte del commons, del acervo de cada proyecto). La presentación no debería tardar más de 7 minutos, porque la mayoría del tiempo va a ser usado para preguntas, respuestas, y reírnos del código. Coordinen via la lista de correos, así tenemos una sola presentación por entorno y no pasa a ser “yo hago mejor django que vos”.

Ayer casi por accidente me crucé con lo que, si no me equivoco, es la famosa papelera de Botnia en Fray Bentos. Uno de los argumentos que escuché por televisión era que Argentina también tenía pasteras sobre el río, pero no encontré nada comparable de tamaño, quizás porque no sé bien adónde buscar. Pero esto es grande.

• Darni dice que hace algo de una semana él vio los accesos un día, y al otro las calles. Después se fueron.
• Yo sigo teniendo los nombres de las calles siguiendo el trazado de las mismas, pero no las calles en sí (osea que no se ven intersecciones ni plazas ni nada realmente útil — todavía)