PDF de programación - PET #6

PET #6 - Nov 2012 - ISSN: 1853-2071

Licencia

Esta revista está disponible bajo una licencia CC-by-nc-sa-2.5.

Es decir que usted es libre de:

Copiar, distribuir, exhibir, y ejecutar la obra

Hacer obras derivadas

Bajo las siguientes condiciones:

Atribución — Usted debe atribuir la obra en la forma especificada por el autor o el licenciante.

No Comercial — Usted no puede usar esta obra con fines comerciales.

Compartir Obras Derivadas Igual — Si usted altera, transforma, o crea sobre esta obra, sólo podrá distribuir la
obra derivada resultante bajo una licencia idéntica a ésta.

Texto completo de la licencia (http://creativecommons.org/licenses/by-nc-sa/2.5/ar/)
En Este Número
Licencia
Con perdón de Cervantes
Empaquetando aplicaciones Django
Pgpymongo y Pgpycouch: Extensiones para PostgreSQL en plpython para acceder a bases de datos
NoSQL documentales
Prymatex
Pyodel
Presente y futuro del entorno de desarrollo Sugar
A los programas los determina el programador, ¿y al programador…?
Ojota
Geek & Poke

2
1
2
6

12
17
23
26
29
31

Staff

Editores: Juan B Cabral Corrector: Walter Alini Sitio: http://revista.python.org.ar

PET es la revista de PyAr, el grupo de usuarios de Python Argentina. Para aprender sobre PyAr, visite su sitio:
http://python.org.ar Los artículos son (c) de sus respectivos autores, reproducidos con autorización. Portada: Catriel
Müller
Editor responsable: Roberto Alsina, Don Bosco 146 Dto 2, San Isidro, Argentina. ISSN: 1853-2071

Con perdón de Cervantes

1

Con perdón de Cervantes
En algún momento de diciembre cuya exactitud no quiero acordarme, reposaban dos hidalgos (uno en Córdoba y otro en
Castelar) con amplia calma y muy buen pasar.

A uno de ellos, por leer libros de fantasía, ocurriósele la empresa de organizar la 3era kermés más grande del lenguaje Python
del 2012, y el otro en su ignorancia lo acompañó.

Molinos de por medio, 11 meses después de su partida estos dos valientes confían en que la épica no les dará la espalda y
contribuyen con estos versos a lograr que vuestras mercedes se vean nutridos por tan magno esfuerzo.
Juan B Cabral - Editor Pet Nro.6 - Co-coord. Gral. PyCon 2012

El Ignorante, el Quijote y el Valentón

Python Entre Todos (número 6, Noviembre 2012) — http://revista.python.org.ar

2

Empaquetando aplicaciones Django

Empaquetando aplicaciones Django

Autor: Daniel F. Moisset

Bio: Desarrollador de Python veterano, emprendedor y domador de serpientes en

Machinalis, docente de CS y ñoño orgulloso.
http://machinalis.com
[email protected]

Web:
Email:

Twitter: @dmoisset

Django permite hacer aplicaciones reusables fácilmente, y es uno de los frameworks con más aplicaciones de terceros
disponibles. Pero muchos autores de aplicaciones no las comparten o lo hacen de una forma impráctica para los usuarios
simplemente porque publicarlas en la forma convencional requiere seguir una serie de pasos poco documentada. Este artículo
permite pasar de ser un autor de aplicación a publicarla en algunos minutos.

Escribo este artículo no como un experto en empaquetado, sino como un novato que documenta su experiencia. En especial,
considerando que la documentación es algo confusa y no se enfoca en aspectos puntuales relacionados con Django.

En este articulo estoy suponiendo que escribiste una aplicación muy piola para Django y que te gustaría que tus usuarios
pudieran bajarla e instalarla desde PyPI (por ejemplo corriendo pip install django-fancy-app) y que pueden instalar la versión
más
ejemplo
p i p   i n s t a l l   - e   h t t p s : / / g i t h u b . c o m / l e c t o r d e p e t / d j a n g o - f a n c y - a p p . g i t ). También voy a suponer que tenés algo de
experiencia básica programando Python.

repositorio

reciente

de

código

(por

del

de

control

Algunas de las explicaciones incluidas son completamente genéricas al empaquetado de cualquier cosa en Python, pero algunos
detalles y supuestos son específicos para aplicaciones Django.

¡Opciones! ¡Opciones!
Lo primero que vas a darte cuenta si googleás un poco sobre cómo empaquetar en Python es que hay muchas opciones:

• distutils
• distutils2
• distribute
• setuptools

Si todavía no te parecen demasiadas, capaz también hayas escuchado de un módulo llamado “packaging” (que es en realidad lo
mismo que distutils2, que será renombrado al incorporarse a la biblioteca estándar de Python 3). Por lo que parece, cada uno de
ellos fue escrito porque «los otros eran muy limitados» o algo por el estilo.

En este artículo voy a estar usando distutils. Lo que me gusta de distutils es que viene incluido en la biblioteca estándar de
Python 2.x (que si estás desarrollando para Django, es la versión que estás usando), y para aplicaciones Django normalmente es
lo suficientemente bueno. Aparentemente el panorama es que todo está convergiendo hacia distutils2, que supuestamente va a
ser compatible hacia atrás una vez que se incorpore (bajo el nombre “packaging”) en Python 3. Para más información, te
recomiendo leer <http://guide.python-distribute.org/introduction.html#current-state-of-packaging>

Python Entre Todos (número 6, Noviembre 2012) — http://revista.python.org.ar

Primeros pasos

3

Primeros pasos
Lo primero que necesitás hacer es decidir dos nombres. El primero de ellos es el nombre en PyPI, es decir el nombre que tus
usuarios van a escribir al hacer p i p   i n s t a l l   … . El segundo es el nombre en Python, que tiene que ser un identificador valido en
Python (alfanumérico y guiones bajos, sin espacios, etc.), que es lo que tus usuarios van escribir dentro del código al poner
i m p o r t   … , y/o lo que agregarán en la opción I N S T A L L E D _ A P P S de su proyecto.

No hay una convención única para estos nombres. La que a mí me gusta son palabras separadas por guión común, con un prefijo
d j a n g o - para el nombre en PyPI; y palabras separadas con guión bajo para nombres en Python, sin el prefijo d j a n g o . En el
ejemplo de este artículo vamos a seguir esta convención, con lo cual el nombre en PyPI será d j a n g o - f a n c y - a p p y el nombre en
Python va a ser f a n c y _ a p p .

La organización de directorios ideal para empaquetar es tener tu aplicación en un directorio llamado con el nombre en Python.
Este directorio debería quedar un nivel adentro de la raíz de tu árbol de control de revisiones. De este modo el directorio raíz
queda reservado para archivos de control que son usados por las herramientas de empaquetado, archivos R E A D M E , directorios de
documentación, etc.

Necesitás crear dos archivos en la raíz para que funcione el sistema de empaquetado: uno llamado s e t u p . p y y otro llamado
M A N I F E S T . i n . El segundo no es un requisito el 100% del tiempo, pero casi seguro vas a necesitarlo. Además, el proceso de crear
paquetes va a crear más archivos y carpetas llamados:

• b u i l d / .
• d i s t / .
• d j a n g o _ f a n c y _ a p p . e g g - i n f o / (esto usa el nombre PyPI con guiones bajos en vez de altos, para confundir un poco más).
• M A N I F E S T .

así que asegurate que estos nombres estén disponibles (es decir, no crees archivos o directorios con estos nombres, y no los
pongas en tu repositorio de control de revisiones -lo más probable es que quieras decirle que ignore estos archivos-).

Escribiendo los archivos de control
La mayoría de los archivos s e t u p . p y se ven así:

f r o m d i s t u t i l s . c o r e i m p o r t s e t u p

s e t u p (
. . . # m u c h o s a r g u m e n t o s n o m b r a d o s q u e u s a s e t u p ( )
)

Este archivo es en efecto un script Python, y sigue la sintaxis estándar de cualquier programa en Python. Esta es la lista de los
argumentos nombrados que normalmente te van a hacer falta:
n a m e :

El nombre en PyPI de tu aplicación

v e r s i o n :

Una cadena de la forma ‘1.2’ o ‘0.3.1’. La forma de esta cadena no es del todo libre, ya que se usa para comparar versiones
cuando se instala desde archivos de requerimientos, por ejemplo si el archivo r e q u i r e m e n t e s . t x t del usuario indica
d j a n g o - f a n c y - a p p > = 1 . 3

d e s c r i p t i o n :

Una descripción de un renglón, que se usa en los listados del sitio de PyPI

l o n g _ d e s c r i p t i o n :

Una descripción más detallada. Esto se va a ver en la página de tu aplicación dentro de PyPI. Podés usar texto formateado
en ReST. En una sección más adelante, muestro algunos trucos útiles para llenar este campo.

a u t h o r :

Tu nombre
a u t h o r _ e m a i l :

Tu dirección de correo electrónico

u r l :

Python Entre Todos (número 6, Noviembre 2012) — http://revista.python.org.ar

4

Agregando una descripción

Una URL que va a mostrarse en las descripciones del proyecto. Algunas personas apuntan aquí a una página web del
proyecto, otros un enlace a un repositorio público como los de github o bitbucket.

c l a s s i f i e r s :

Esta es una lista de etiquetas para herramientas que hacen índices de paquetes. Para las aplicaciones Django, casi seguro
que querés ponerle al menos las siguientes:

• E n v i r o n m e n t   : :   W e b   E n v i r o n m e n t ,
• I n t e n d e d   A u d i e n c e   : :   D e v e l o p e r s ,
• F r a m e w o r k   : :   D j a n g o ,
• P r o g r a m m i n g   L a n g u a g e   : :   P y t h o n ,
• tal vez T o p i c   : :   I n t e r n e t   : :   W W W / H T T P   : :   D y n a m i c   C o n t e n t ,
• Uno de los clasificadores de D e v e l o p m e n t   S t a t u s y uno de L i c e n s e

Hay un listado completo en <http://pypi.python.org/pypi?%3Aaction=list_classifiers>

p a c k a g e s :

Esta es una lista de directorios con archivos Python que se van a instalar. En el caso más simple, esto va a ser [‘fancy_app’].
Pero si tenés más directorios o una je