Las gemas de Ruby son paquetes de librerías para Ruby que se instalan en el sistema y quedan listas para ser usadas, con un simple require o con mecanismos que aporta el propio sistema de gemas para Ruby.

El gestor de gemas: rubygems

En distribuciones de GNU/Linux, e instalaciones automáticas para Windows, se nos habilita un comando, generalmente, que nos permite agregar librerías y código de un repositorio muy extenso de código listo para usar. Esto es conocido como el gestor de gemas, rubygems, o simplemente gem.

El gestor de gemas es un comando que nos permite listar las gemas instaladas, buscar gemas remotas o localmente (de las instaladas), instalar, actualizar y eliminar gemas. Se puede saber si está instalado simplemente ejecutando:

gem --version

La última versión a día de hoy es la 1.8.12, actualizar el sistema de gemas es tan simple como ejecutar:

gem update --system

Instalar una gema

Por ejemplo, si queremos usar el código siguiente:

require "rubygems";
require "json";
 
puts [ "hola a todos", 12, "C/Sin nombre, 25" ].to_json

Tendremos que instalar previamente la gema json. Para instalarla, solo tenemos que ejecutar el siguiente comando:

$ sudo gem install json
[sudo] password for marubio: 
Building native extensions.  This could take a while...
Successfully installed json-1.6.4
1 gem installed
Installing ri documentation for json-1.6.4...
Installing RDoc documentation for json-1.6.4...

Como se puede apreciar, se instala la gema y se genera la documentación para ri y rdoc. La generación de la documentación es bastante lenta y si tenemos que instalar muchas gemas, puede ser algo tedioso. Se puede eliminar esta tarea agregando al comando de instalación: --no-ri --no-rdoc

Ahora, cuando listemos los paquetes instalados podremos ver:

$ sudo gem list
 
*** LOCAL GEMS ***
 
json (1.6.4)

Nos indica la versión, ya que podríamos tener varias versiones instaladas y conviviendo, y desde el código emplear la que requiramos específicamente. Si queremos instalar una versión específica de un paquete, podemos hacerlo agregando la opción, por ejemplo: --v=1.6.1

Buscando una gema

Si queremos buscar una gema específica del directorio de gemas, podemos hacerlo a través de la propia página web: RubyGems; o a través del comando:

$ gem search -r jsonn
 
*** REMOTE GEMS ***
 
active_record_serialize_json (0.1.2)
activejson (0.1.2)
activeresource_json_patch (0.0.1)
assert_json (0.1.1)
capcode-render-json (0.2.0)
capybara-json (0.1.1)
colorful_json (0.9.1)
csv2json (0.2.0)
cucumber-json (0.0.2)
dm-json-search (0.0.3)
[...]

La base de datos de gemas tiene la friolera de más de 32 mil gemas, por lo que, no es de extrañar que ante algo trivial (como JSON) puedan aparecer cientos de gemas. A la hora de buscar deberemos de ser más precisos con los términos a elegir.

Conclusiones

Ha sido una introducción muy ligera a este entorno de gestión de paquetes de Ruby, lo sé, pero al menos complementa un poco la entrada de hace algunos meses sobre Bundler y da un poco de información sobre los comandos más usuales a la hora de instalar una librería en Ruby, ya sea para código scripting o para Rails.

Después de un recorrido por Symfony (PHP), Rails (Ruby) y Django (Python), he decidido echarle un vistazo a Catalyst (Perl) para ver qué novedades integra y en qué mejora, tanto a nivel de rendimiento, como a nivel de desarrollo, la generación de sitios web dinámicos.

Perspectiva MVC

Cada entorno integra MVC de una forma diferente, incluso lo que se entiende por MVC, desde los primeros libros a finales de los 70 y principios de los 80, es un esquema en el que la Vista puede interactuar con el modelo, al igual que el controlador con la vista y con el modelo.

En Rails, se presenta el fat model, donde la codificación referente a base de datos se realiza en estos, y el flujo de la aplicación recae en los controladores, que deciden qué tipo de vista o presentación de la información emplear, dando facilidades para la presentación en HTML, JSON, XML… e incluso vía email.

En cambio, Django, no dispone de controlador como tal, ya que lo nombran por defecto como views, siendo esta la entidad que controla el flujo y la presentación, ayudada de la plantillas usando DTL. En este caso, la parte de MVC queda más difusa y ellos mismos explican en su web, que se podría decir más bien que Django es MTV (Model-Template-View).

Catalyst, sin embargo, tiene más semejanza a Rails en este sentido. Tiene un parte para los controladores, una parte para los modelos y otra parte para las vistas. Así mismo, las vistas se desarrollan, al igual que Django y Rails, con un sistema de plantillas (templates).

Al crear un proyecto, tan solo ejecutando el siguiente comando, se genera la estructura de ficheros que podemos ver a continuación:

$ catalyst.pl miproject
created "miproject"
created "miproject/script"
created "miproject/lib"
created "miproject/root"
created "miproject/root/static"
created "miproject/root/static/images"
[...]
$ tree
.
├── Changes
├── lib
│   ├── miproject
│   │   ├── Controller
│   │   │   └── Root.pm
│   │   ├── Model
│   │   └── View
│   └── miproject.pm
├── Makefile.PL
├── miproject.conf
├── miproject.psgi
├── README
├── root
│   ├── favicon.ico
│   └── static
│       └── images
│           ├── btn_120x50_built.png
│           ├── btn_120x50_built_shadow.png
│           ├── btn_120x50_powered.png
│           ├── btn_120x50_powered_shadow.png
│           ├── btn_88x31_built.png
│           ├── btn_88x31_built_shadow.png
│           ├── btn_88x31_powered.png
│           ├── btn_88x31_powered_shadow.png
│           └── catalyst_logo.png
├── script
│   ├── miproject_cgi.pl
│   ├── miproject_create.pl
│   ├── miproject_fastcgi.pl
│   ├── miproject_server.pl
│   └── miproject_test.pl
└── t
    ├── 01app.t
    ├── 02pod.t
    └── 03podcoverage.t

10 directories, 25 files

En el directorio lib/miproject es donde está el código principal.

Los controladores

A diferencia de otros entornos, las URLs o rutas para acceso a los métodos de Catalyst son implícitas a las subrutinas de cada paquete que está en el directorio (o paquete) de controladores. Por ejemplo, si editamos el fichero lib/miproject/Controller/Root.pm y agregamos el siguiente código:

sub libros :Global {
    my ($self, $c) = @_;
    $c->response->body ( "listado de libros!" );
}

Al ejecutar el servidor de pruebas: script/miproject_server.pl; podremos ver la siguiente tabla:

[debug] Loaded Private actions:
.----------------------+--------------------------------------+--------------.
| Private              | Class                                | Method       |
+----------------------+--------------------------------------+--------------+
| /default             | miproject::Controller::Root          | default      |
| /end                 | miproject::Controller::Root          | end          |
| /libros              | miproject::Controller::Root          | libros       |
| /index               | miproject::Controller::Root          | index        |
'----------------------+--------------------------------------+--------------'

Al cargar la página http://localhost:3000/libros podemos ver el resultado de la ejecución de la subrutina escrita.

La vista

Hemos realizado antes una salida directa desde el controlador, pero lo suyo es crear una vista. El sistema de plantillas de Perl se denomina TT. Es parecido al que se usa en JSP e incluso al que usa la DTL (Django Template Library), pero difiere bastante. Vamos a generar una vista primero:

$ script/miproject_create.pl view HTML TT

Con esto nuestro directorio de View se completa con la generación de un módulo de Perl HTML.pm. Ahora creamos una vista con la siguiente información en la ruta root con el nombre listado.tt:

<h1>Hola mundo!</h1>
 
<p>[% libros %]</p>

Para lo que habrá que cambiar la subrutina escrita anteriormente a la siguiente (también se puede cambiar el nombre y agregar como una completamente nueva):

sub libros :Global {
    my ($self, $c) = @_;
    $c->stash(template => "listado.tt");
    $c->stash(libros => "no hay libros");
}

Los modelos

Tanto Django como Rails, e incluso Doctrine, tienen sistemas de migraciones o sincronización con base de datos. Catalyst no dispone de estos mecanismos. Puede generar sus modelos de una conexión de base de datos con tablas ya creadas, pero no al contrario.

No obstante, su ORM es bastante potente. Por ejemplo, pongamos que creamos una base de datos SQLite (supongamos que en /tmp/libros.db):

PRAGMA foreign_keys = ON;
CREATE TABLE libros (
     id INTEGER PRIMARY KEY,
     titulo TEXT
);
 
CREATE TABLE autores (
     id INTEGER PRIMARY KEY,
     nombre TEXT,
     apellidos TEXT
);
 
CREATE TABLE libros_autores (
     libro_id INTEGER REFERENCES libros(id) ON DELETE CASCADE ON UPDATE CASCADE,
     autor_id INTEGER REFERENCES autores(id) ON DELETE CASCADE ON UPDATE CASCADE,
     PRIMARY KEY (libro_id, autor_id)
);
 
INSERT INTO libros VALUES (1, 'Diseño Ágil con TDD');
INSERT INTO libros VALUES (2, 'No me hagas pensar');
INSERT INTO libros VALUES (3, 'Hacking Etico');
INSERT INTO libros VALUES (4, 'Perl Best Practices');
 
INSERT INTO autores VALUES (1, 'Carlos', 'Ble');
INSERT INTO autores VALUES (2, 'Steve', 'Krug');
INSERT INTO autores VALUES (3, 'Carlos', 'Tori');
INSERT INTO autores VALUES (4, 'Damian', 'Conway');
 
INSERT INTO libros_autores VALUES (1, 1);
INSERT INTO libros_autores VALUES (2, 2);
INSERT INTO libros_autores VALUES (3, 3);
INSERT INTO libros_autores VALUES (4, 4);

Generamos nuestros modelos con el siguiente comando:

$ script/miproject_create.pl model  DB DBIC::Schema \
     MiProject::Schema create=static \
     dbi:SQLite:/tmp/libros.sqlite \
     on_connect_do="PRAGMA foreign_keys = ON"

Con esto nos genera un fichero de esquema en el directorio Model, con lo que tendremos el acceso a la base de datos configurada. Si quisieramos probar, tan solo necesitaríamos ejecutar lo siguiente. Modificamos la subrutina de nuevo:

sub libros :Global {
    my ($self, $c) = @_;
    $c->stash(template => "listado.tt");
    $c->stash(libros => [$c->model('DB::Libro')->all]);
}

Y también el fichero de plantilla por lo siguiente:

<h1>Hola mundo!</h1>
 
[% FOREACH libro IN libros -%]
[% tt_autores = []; tt_autores.push(autor.apellidos) FOREACH autor = libro.autores %]
<p>[% libro.titulo %] - [% tt_autores.join(', ') | html %]</p>
[% END -%]

Por último, agregamos las referencias necesarias en Libro.pm y Autore.pm (es lo malo del pluralize del inglés cuando se usan palabras castellanas):

__PACKAGE__->many_to_many(libros => 'libros_autores', 'libro');

Y esto para Autore.pm:

__PACKAGE__->many_to_many(autores => 'libros_autores', 'autor');

Con esto ya tendríamos un listado muy simple en funcionamiento. Puedes ver el tutorial completo (con un CRUD de ejemplo y más cosas aún) en la siguiente dirección (en inglés): Tutorial.

Conclusiones

El entorno proporciona las bases que proporcionan el resto de frameworks, su simpleza en las rutas y su formato de ORM hace que la programación de elementos sea bastante simple y rápida, no obstante, hay ciertos elementos con los que hay que tratar y revisarlos bien, leer bien la documentación y tratar de entenderlos, si no queremos toparnos con ningún problema a la hora de realizar cualquier entorno.

Personalmente, me ha gustado la experiencia y el entorno en sí, la programación con los módulos de Perl, lo documentado que queda todo si se siguen las líneas y el hecho de que no hace falta escribir mucho código para conseguir que el sistema funcione bien, hacen que sea un framework muy cómodo de utilizar.

El lenguaje haXe, se presenta como un meta-lenguaje, un lenguaje que se compila resultando en otro diferente, como pueda ser JavaScript, PHP, Java o Neko, por lo que puede emplear cualquier entorno de ejecución conocido por el programador. Dicho de otra forma, este es un lenguaje para dominarlos a todos…

El lenguaje

Echándole un vistazo a la sintaxis del lenguaje, podríamos decir que el lenguaje es muy parecido a JavaScript, pero con definición de tipos. La declaración es parecida a Pascal o Modula-2, usando dos puntos, pero sin embargo, la forma de los arrays es más como las plantillas de Java.

Las estructuras condicionales son las que están disponibles en lenguajes como PHP, C, Java y demás, con algunos matices, por ejemplo, con el uso de iteradores, con lo que el for es más parecido a Python o Java, por ejemplo. Tiene una forma tal que así:

import php.Lib;
 
class Index {
    static function main() {
        var p = new Point(-1,65);
        trace(p);
    }
}
 
class Point {
    var x : Int;
    var y : Int;
    public function new(x,y) {
        this.x = x;
        this.y = y;
    }
    public function toString() {
        return "Point("+x+","+y+")";
    }
}

Este código (tomado de su web, sección de tipos) se encarga de definir una clase Point, con un constructor que inicializa los atributos internos (x e y) y una función especial para representar el dato en modo texto (como en Java).

Lo suyo sería que se particionase como clases independientes, e incluso se creasen paquetes, una vez se programe en serio con el lenguaje.

La compilación

En Debian, el compilador viene en el repositorio. Llama la atención el hecho de que se instala de la mano de Neko (que es otro lenguaje similar, que se puede compilar en otros, pero que además tiene una VM propio e integración con Apache).

Generar el código visto anteriormente en PHP, es tan simple como ejecutar esto:

haxe -main Index -php www

Nos creará un directorio www en la ruta en la que estemos que tendrá un directorio lib y un index.php en la base con los comandos básicos para ejecutar el código programado. Lo podemos ejecutar desde consola (si tenemos el php-cli), así:

$ php www/index.php
Index.hx:6: Point(-1,65)

Conclusiones

Últimamente se van escuchando cada vez más lenguajes nuevos que salen, buenos lenguajes con muchas nuevas características que facilitan mucho la vida a los programadores, pero que, por el simple hecho de ser más completos, tienen una curva de aprendizaje más alta.

Lo que propone HaXe, en sí, es un solo lenguaje, un lenguaje muy completo, con todas las características de alto nivel que tienen todos los lenguajes, fácil y muy parecido a los lenguajes más usados de hoy en día, por lo que su entrada a él sea rápida, pero además, muy versátil, como los lenguajes scriptting, y ajustable a las necesidades de producción, gracias a que se puede compilar en C++, Java, C#, PHP, JavaScript, Flash y Neko.

En mi opinión, es una muy buena propuesta, ya que se podría emplear para generar el código necesario para realizar la web a nivel de servidor, cliente, e incluso algunos códigos a nivel de aplicación de escritorio, todo en un solo lenguaje.

Versión PHP

Empezaremos con la complicada. Este código se encarga de descargar el código del RSS y deserializar el XML en un array, para poder tratarlo a posteriori. El tratamiento lo haré en plan cutre, ya que me intentaré, sobretodo, basar en el proceso de descarga y deserialización.

Para esto, se requiere de una librería que no suele venir con PHP, pero sí está en PEAR, con lo que, se puede instalar fácilmente ejecutando la siguiente línea de comandos:

pear install XML_Serializer

Con esto, el código, en plan simple, sería el siguiente:

<?php
 
 
include 'XML/Unserializer.php';
 
function xml_to_array( $data ) {
    $options = array(
        "addDecl"            => true,
        "encoding"           => "utf-8",
        "mode"               => XML_SERIALIZER_MODE_SIMPLEXML,
        "indent"             => "    ",
        "linebreak"          => "\n",
        "scalarAsAttributes" => true,
        "attributesArray"    => '_a',
        "contentName"        => '_c',
        "rootName"           => 'rss'
    );
 
    $unserializer = new XML_Unserializer($options);
    $unserializer->unserialize($data);
    $doc = $unserializer->getUnserializedData();
 
    return $doc;
}
 
$data = xml_to_array(file_get_contents('http://www.debian.org/News/news'));
?>
<html>
<body>
    <? foreach ($data["item"] as $noticia) { ?>
    <h1><a href="<?=$noticia["link"]?>"><?=$noticia["title"]?></a></h1>
    <p class="date"><?=date("d/m/Y H:i", strtotime($noticia["dc:date"]))?></p>
    <p class="desc"><?=$noticia['description']?></p>
    <? } ?>
</body>
</html>

No pinta mal, conseguimos lo que nos proponemos sin tener muchas complicaciones.

Ahora la versión bonita

En Rails las cosas siempre tienden a ser más simples, o al menos mucho más cortas, muestra de ello, es la versión del código anterior en versión Rails. Este sería:

  def noticias
    require 'rss/1.0'
    require 'rss/2.0'
    require 'open-uri'
 
    source = "http://www.debian.org/News/news"
    content = ""
    open(source) do |s| content = s.read end
    @rss = RSS::Parser.parse(content, false)
  end

Aunque he puesto los require dentro de la función, realmente podrían ponerse en otro sitio (como en environment.rb) y no requieren de la instalación de ninguna gema extra. En la vista sería tan solo usar el código de la siguiente forma:

<% @rss.items.each do |i| %>
    <h1><%= link_to i.title, i.link %></h1>
    <p class="date"><%=i.date.strftime("%d/%m/%Y %H:%M")%></p>
    <p class="desc"><%=simple_format(i.description)%></p>
<% end %>

Los helpers ayudan bastante en la creación del código, haciendo que los enlaces se hagan de forma simple, así como el formateado de la fecha, y el parseo del texto para HTML.

Conclusiones

He estado revisando el repositorio PEAR, donde he podido ver que había un par de paquetes de RSS, uno de ellos sin mantenimiento ya (XML_RSS), y el resto de blogs que he visitado lo hacen como he mencionado, por lo que, obliga a conocer los distintos formatos de los que se van a rescatar noticias, ya sean Atom, RSS (la versión que corresponda), etc. Me parece que en este sentido Rails ha demostrado ser más serio o aplicado.

Después de realizar una pequeña búsqueda por Internet, he visto que, en la propia página de PHP, ya tienen medio resuelto el problema y, funciona bastante bien… según leo en un ejemplo de :

<?php
function exception_error_handler($errno, $errstr, $errfile, $errline ) {
    throw new ErrorException($errstr, 0, $errno, $errfile, $errline);
}
set_error_handler("exception_error_handler", E_USER_ERROR);
 
/* Trigger exception */
strpos();
?>

Si lanzamos la ejecución del código, veremos que ya no se sucede el típico Fatal Error, sino una excepción no capturada, con lo que, si envolviésemos el código strpos con try ... catch, obtendríamos que el programa ya no deja de funcionar.

Hay que tener en cuenta de que PHP no tiene solo errores, sino también noticas (NOTICE), avisos de elementos en desuso (DEPRECATED) y avisos (WARNING), que podría capturarse si no indicamos el parámetro E_USER_ERROR como segundo parámetro de set_error_handler.

¿Para cuándo lo incluirán este cómo como por defecto en la distribución estándar de PHP?

Entonces, si estamos desarrollando y, por arte y gracia del destino necesitamos de una nueva columna en una tabla… y peor aún, si el sistema ya está en producción, ¿cómo lo hacemos?

¡South al rescate!

South es un sistema de migraciones parecido al que viene con Rails, solo que: es automático.

El sistema se basa en la creación (y activación) del sistema de migraciones por aplicación. Cuando se activa, se crea un subdirectorio de migrations en la aplicación, donde se almacenan ficheros de migración. En principio, se agregan las migraciones necesarias para la creación de los modelos que se hayan agregado en el fichero models.py nada más comenzar.

Esto se consigue, antes de ejecutar el comando syncdb, algo como esto:

./manage.py schemamigration myapp --initial

Siendo myapp el nombre de la aplicación sobre la que se quiere activar el sistema de migraciones.

Y en el momento que se tenga que cambiar alguna de las tablas, para realizar la agregación o cambio de algún campo (o la eliminación, claro), tan solo hay que grabar el fichero models.py con el cambio y ejecutar en consola:

./manage.py schemamigration myapp --auto

En este punto, el sistema agrega una migración con los cambios a insertar en la base de datos para realizar el cambio del estado de las tablas en la versión anterior para adecuarlo a la definición actual.

Cuando se ejecuta syncdb el sistema informa de que no puede hacer nada con esa aplicación y que se debe de ejecutar migrate para realizar las migraciones. En este punto ya es donde se comienza a ver y notar el parecido con Rails, ya que el comando es exactamente el mismo, la única diferencia, es que no hemos tenido ni que crear ni que escribir ningún fichero (salvo el conocido models.py).

La única pega, de momento, con este sistema, es que si nos equivocamos, no podemos echar atrás una migración. La única forma de avanzar, al igual que con los sistemas de control de versiones, es deshacer lo que queramos en el fichero de models.py y volver a crear una nueva migración.

Desde el principio… ¿cómo se instala esto?

La parte buena, es que se instala fácilmente con el siguiente comando:

easy_install South

El paquete está publicado en el Cheese Shop, con lo que, se baja e instala de forma fácil. Para que esté disponible en nuestro proyecto, solo tenemos que agregarlo al settings.py (la aplicación south), y ya estarán disponibles los comandos para manage.py.

Si la aplicación sobre la que queremos usar las migraciones ya existe y se han creado modelos con syncdb, en caso de crear la primera migración, puede pasar que al ejecutar migrate, el sistema falle diciendo que la tabla que se intenta crear ya existe. Esto es porque, cuando el proyecto ya existe y se ha usado syncdb para la aplicación en concreto, necesita la ejecución del siguiente comando a nivel de consola:

./manage.py convert_to_south myapp

Con esto, el sistema toma como realizada la migración inicial y puedes seguir a partir de ahí.

Conclusiones

Django es un buen sistema para desarrollo de aplicaciones web, como ya dije anteriormente. Como muchos otros frameworks para desarrollo de aplicaciones web, tiene sus carencias, pero afortunadamente, si se revisa un simple pip search django, donde puede observar que, aparte de lo que viene por defecto con Django, se pueden agregar muchas extensiones muy útiles al sistema… como South.

En principio, si consideramos algo tan simple como el famoso heredoc, que en JavaScript no está soportado, en CoffeeScript es posible de la siguiente forma:

datos = '''
     Estimado lector,
 
     esta es una carta....
     '''

O algo típico como:

potencia = (x, y) ->
    a = 1
    for i in [1..y]
        a *= x
    a
 
alert potencia(5, 2)

Pero no es un nuevo lenguaje que vayan a soportar los navegadores, realmente es una abstracción que finalmente se traduce a JavaScript (ya sea por parte del servidor o del cliente a través de las librerías de javascript correspondientes) y se usa en el navegador. Eso sí, el lenguaje es más completo, ya que incluye cosas que JavaScript no tiene por defecto, y más claro, ya que usa la sintaxis de palabra sobre símbolo (equivalente al use english de Perl).

En la página web oficial de CoffeeScript podemos encontrar un manual extenso y lleno de ejemplos del lenguaje, con su equivalencia en JavaScript. La mayoría de trozos se notan más claros y escuetos en CoffeeScript. No obstante, es lógico que una persona que esté más habituada a leer y escribir código en JavaScript, lo que le costará es ver el acercamiento que intenta realizar este lenguaje.

La sintaxis recuerda un poco a YAML, y por ende a Python, ya que requiere de una indentación para identificar de que pende cada instrucción. Así mismo, en su carencia de la palabra clave return, se parece también un poco Ruby. El uso de las funciones se ha asemejado a las lambda que integran ahora muchos lenguajes (Java se espera que lo tenga para su versión 8 ) y que emplea la flecha o símbolo de conclusión lógica (que es también usado para la definición de funciones en Erlang).

Como buen lenguaje de scripting no requiere que se declare ninguna variable, a diferencia de algunas implementaciones de JavaScript, donde es requerido, sobretodo para fijar el alcance de la misma, y hace uso de las post-condiciones, tal y como se puede ver en Perl y Ruby, en trozos como:

dato = 5 if valor > 5 and valor < 10

Es una de las mejoras que se integran en Ruby 3.1, por lo que, se puede probar en ese mismo entorno, o instalándolo directamente o a través del sistema de NodeJS. El sistema contiene un compilador o traductor que toma el código fuente y lo transforma en las librerías JavaScript necesarias para la página web, por lo que no penaliza el rendimiento de la propia página en sí.

Decir que, en mi parecer, el hecho de que sea un lenguaje que se compila a otro da la buena fe y esperanza de que el código generado sea estándar para todos los navegadores, así como la facilidad de que la implementación del mismo parte de un solo sitio, de una sola definición muy trabajada por el autor. Seguiremos de cerca su evolución.

Cuando un desarrollador realiza un desarrollo que quiere compartir con el mundo, normalmente, lo empaqueta de alguna forma y lo sube a Internet de alguna forma. A día de hoy, es muy común ver mucho código subido a sitios como PHPClasses, PEAR, RubyGems, Cheese Shop, SourceForge, GitHub, BitBucket, etc.

El empaquetado es algo en lo que, cada lenguaje pone un cierto estándar para facilitar la vida a los programadores y usuarios finales de ese código. Es muy común también, ver que muchas veces se empaqueta en ficheros de tipo phar, jar, gem, egg o los más conocidos tar.gz, tar.bz2 y zip. Cada lenguaje pone sus preferencias y convenciones.

La tienda de quesos

El índice general de paquetes Python (donde la gente suele subir sus códigos para compartirlos con la comunidad, suele ser lo que se conoce como Cheese Shop (la tienda de quesos). En este sitio, cada desarrollador puede darse de alta y subir sus códigos de modo que estén disponibles para el instalador de paquetes de Python.

El comando easy_install

La forma más fácil de instalar un huevo de Python, es emplear el comando easy_install, simplemente se ejecuta lo siguiente:

easy_install django

El sistema se conecta al índice general de paquetes y descarga el paquete indicado, así como lo instala una vez ha conseguido bajarlo. En el caso del ejemplo, bajaría el paquete de django, y lo instalaría sin problemas.

El gestor de paquetes de Python: pip

No obstante, para poder instalar de forma local (o vía URL) un paquete, o desinstalarlo, u obtener información del mismo, necesitamos otro comando más completo como este: pip; este comando se encarga de desempaquetar el huevo e instalarlo en el sistema.

Estos comandos se encuentra con el setuptools de Python, que generalmente se instala en todos los sistemas base Python que vienen instalados por defecto en la mayoría de distribuciones GNU/Linux. En MacOS X suele venir por defecto easy_install, y ejecutando lo siguiente, se puede instalar el comando pip:

easy_install pip

Los comandos, según la opción help de pip, son los siguientes:

• freeze: muestra los paquetes instalados.
• install: instala un paquete egg
• search: busca un paquete egg<7em> en el sistema de índices (tiemda de queso).
uninstall: desinstala un paquete
• zip/unzip: comprime o descomprime, respectivamente, un paquete.