Bitácora de Vuelo (Publicaciones sobre distribución)

Mi posición con respecto a pinning

Facundo Batista — Wed, 09 Nov 2022 22:19:00 GMT

Si ya voy mezclando palabras raras en el título pueden empezar a adivinar que este es un post técnico, y tendrán razón.

¿Qué significa pinning? Un montón de cosas, pero en el mundo del software, o al menos en la parte de distribución de software, significa especificar exactamente la versión de una dependencia.

Por ejemplo, yo puedo hacer un programejo que usa la biblioteca requests, y no me importa la versión, entonces en la lista de dependencias pongo requests y ya. Pero si quiero especificar exactamente qué versión de esa biblioteca necesito, pondría algo como requests == 2.7.1. Eso es pinnear (mezclando ahora inglés y castellano) la versión de la dependencia, que es como agarrarla con un alfiler para que no se mueva y siempre sea la misma.

¿Cuándo tiene sentido hacer eso y cuándo no? ¿Depende del entorno donde correrá mi programejo? ¿De las dependencias que estoy usando? ¿De la forma de distribución? Un poco de todo eso apunta a contestar este post.

Entonces...

Mi posición con respecto a pinning

Ya sabemos que los extremos son malos. Traducido al tema que nos atañe, podemos decir que no queremos ni nada pinneado nunca, ni todo pinneado todo el tiempo.

El problema de "nada pinneado nunca" es que es muy difícil poder garantizar la calidad del sistema que estamos armando. Si en desarrollo usamos la biblioteca versión X, pero luego cuando desplegamos todo en un servidor termina instalando la versión Y, puede ser que nos explote todo. O peor, que parezca funcionar, pero que no funcione correctamente. Y si lo distribuimos es aún más complicado: si el sistema lo instalan un montón de personas en sus computadoras vamos a tener mil combinaciones de distintas versiones.

Por otro lado, si tenemos "todo pinneado todo el tiempo", rompemos la evolución del software que contiene nuestro sistema. La evolución es un concepto central, no podemos cortar la evolución de las dependencias de nuestro software porque terminamos atados a versiones viejas. Y no es un problema de alguna funcionalidad más o menos, sino de seguridad: a menos que tengamos atrás un equipo de especialistas en seguridad haciéndose cargo del mantenimiento de versiones viejas, tenemos que tratar de usar todo lo nuevo en todos lados.

Entonces, tenemos que encontrar un balance entre ambos extremos, que es lo que les comento en el resto del post.

Tengamos en cuenta que queremos distintos comportamientos si tenemos bibliotecas o aplicaciones, y en este último caso dónde correrán las aplicaciones, si del lado del cliente (luego de que empaquetamos el software) o en un servidor (que desplegamos directamente).

Bibliotecas

Si estamos trabajando con bibliotecas, las mismas tienen que ser lo más flexibles posible, ya que van a ser usadas de maneras que no se pueden prever: nunca vamos a tener el contexto en el qué se usarán nuestras bibliotecas.

Debemos especificar qué dependencias se necesitan, pero ser lo más libres y genériques posibles con respecto a las versiones, luego la aplicación que use nuestra biblioteca especificará la versión, o no. No es de nuestra incumbencia, nuestra biblioteca debería ser independiente de las versiones de sus dependencias... y aunque ya sabemos que esto no es posible en su totalidad, debemos tratar de restringir las versiones lo menos posible.

En otras palabras, está mal definir que nuestra biblioteca necesita la dependencia X en la versión == 2.7.1, pero está bien definir que la necesita en una versión => 2 o incluso => 2; != 2.0.4, en caso de que haya alguna incompatibilidad puntual. Y después será la aplicación la que defina en qué versión necesita sus propias dependencias, y se hará el análisis en conjunto para determinar si hay un conflicto. Si la biblioteca defina una dependencia X en una versión específica, y la aplicación también depende de la misma X, está condicionada a usar sólo esa versión. Peor aún, si la aplicación necesita las bibliotecas foo y bar, y foo define la dependencia X en una versión y bar define la misma dependencia X en otra versión, la aplicación directamente no podrá usar ambas foo y bar.

Entonces, recapitulemos: para las bibliotecas seamos lo menos específicos posible en las versiones de sus dependencias. Arranquemos con no indicar ninguna versión en ninguna dependencia, y vayamos agregando restricciones con el tiempo, sólo si encontramos alguna incompatibilidad.

Aplicaciones

Con las aplicaciones es diferente. En el momento en que empaquetamos una aplicación para distribuirla, o la desplegamos en servidores para ser usada, queremos poder garantizar que se ejecutará correctamente de cara a les usuaries finales.

La calidad de la aplicación la garantizamos con distintas evaluaciones que hacemos, que pueden ser pruebas de unidad, pruebas de integración, pruebas manuales. Un proyecto robusto siempre tendrá alguna combinación de todas estas pruebas que se realizarán para determinar la calidad de una determinada versión de la aplicación.

Pero esta versión de la aplicación, ¿qué versión de cada una de sus dependencias utilizará? Si corremos todas las pruebas para la versión que queremos liberar de nuestra aplicación usando la versión X de una dependencia, pero al momento de empaquetarla o desplegarla en un servidor se termina usando la versión Y de esa dependencia, en realidad las pruebas que corrimos no son válidas.

Tengamos en cuenta que en realidad no hay mucha diferencia entre si a la aplicación la empaquetamos para distribuirla o la desplegamos en un servidor para ser usada. En general tanto el proceso de empaquetado como el de despliegue terminarán instalando nuevamente las dependencias necesarias, y a menos que todas las versiones estén especificadas, no tenemos control de cuales serán usadas.

En otras palabras, para garantizar la calidad de la aplicación tenemos que pinnear las versiones de las dependencias, correr toda la batería de pruebas que tengamos utilizando esas dependencias, y luego empaquetar o desplegar la aplicación usando exactamente esas dependencias.

Pero si tenemos todo pinneado, volvemos al problema del que hablábamos antes de poder evolucionar, quedamos atrapados en versiones viejas con posibles problemas sin corregir. O peor, con fallas de seguridad expuestas.

La forma más piola que he encontrado de tanto poder garantizar la calidad final como también de evolucionar en el tiempo es tener dos listas de dependencias.

La primera lista tendrá las dependencias directas de nuestra aplicación (no las dependencias de las dependencias) de la forma más laxa posible: similar a lo que hacemos con las bibliotecas, a priori no especificaremos ninguna restricción, y sólo las agregaremos con el tiempo si encontramos incompatibilidades puntuales.

La segunda lista tendrá todas las dependencias de nuestra aplicación y a la vez todas las dependencias de las dependencias, y las dependencias de las dependencias de las dependencias, etc., con la versión específica con que fueron instaladas. Todas las pruebas que correrá el desarrollador, o el sistema de CI/CD (Continuous Integration / Continuous Delivery) que tengamos, se harán utilizando esta segunda lista con todo bien especificado. Y el proceso posterior de empaquetado o despliegue también utilizará esta segunda lista, con lo cual terminamos garantizando la calidad de la aplicación. Incluso, si dudamos de la procedencia de los archivos de nuestras dependencias, podemos hasta sacar el hash de las mismas y luego validarlas; entonces no sólo indicamos que los tests se hacen con la versión foo == 2.1.7 sino que también podemos validar que cuando el server instale esa versión específica el archivo con el que lo haga sea exactamente igual al que usamos nosotros, y nadie nos vendió gato por liebre en el medio (lo que sería un tipo de ataque MITM).

Entonces, ya sabemos que tenemos dos listas para las dependencias de nuestra aplicación, la laxa que nos permite evolucionar y a partir de la cual se arma la muy específica sobre la cual se valida calidad y libera la aplicación.

¿Cómo vamos de una lista a la otra? En tiempo de desarrollo. Será responsabilidad de nosotres les desarrolladores el cada tanto (no tiene que ser todo el tiempo) generar el entorno de desarrollo desde cero utilizando la lista laxa y generar a partir de esa instalación la lista específica. Las distintas herramientas que nos permiten trabajar con entornos de desarrollo en general también nos dan la posibilidad de generar la lista específica a partir del entorno creado (por ejemplo en fades tenemos la opción --freeze).

Para terminar, tengamos en cuenta que todas las dependencias que vengo mencionando son las de producción, aquellas bibliotecas que nuestra aplicación necesita para finalmente correr.

Pero también tenemos aquellas dependencias de desarrollo: todas las bibliotecas y utilidades que usaremos les desarrolladores para, justamente, desarrollar la aplicación. Estas dependencias no se instalarán, incluirán, ni usarán en el paquete que armemos para distribuir la aplicación o en el servidor. Un ejemplo de este tipo de dependencias podría ser pytest, el corredor de pruebas de unidad.

Para estas dependencias tendremos otra lista, separada de las de producción. Hay distintas formas de manejar esta separación; por ejemplo, si utilizamos archivos de dependencias podemos tener un requirements.txt para las de producción y requirements-dev.txt para las desarrollo.

El punto es que a las dependencias de desarrollo no las tenemos que pinnear para nada (obviamente, a menos que encontremos alguna incompatibilidad o bug en particular). Siempre utilizaremos lo último de lo último cuando armemos los entornos de desarrollo, y si en algún momento algún test falla porque las herramientas que utilizamos evolucionaron (por ejemplo, flake8 detectando un caso nuevo) corregiremos nuestro código y seguiremos adelante. Pero no hay motivo alguno para pinnearlas.

El futuro del empaquetado en Python

Facundo Batista — Sun, 26 Sep 2021 23:44:00 GMT

Ok, ok, es un poco pretencioso mi título, pero es que estoy muy contento de anunciar la segunda liberación de un proyecto que maduró en mi cabeza por unos meses y ya armé una prueba de concepto.

La alegría viene en parte porque no sólo la prueba de concepto fue más exitosa de lo que pensaba (el sistema hace lo que quería que haga de forma sorprendentemente genérica y robusta), sino que todo esto pasa en los días que cumplo 20 años programando en Python :)

En verdad lo que ya tengo armado es más que una prueba de concepto. Está funcionando todo lo que quería, aunque le faltan algunas funcionalidades básicas para todo lo que tengo imaginado, tests, mejorar el código etc. Podemos decir que está en estado "alfa".

Pero aún versión alfa y todo, ya está publicado: PyEmpaq v0.2.1.

En la página del proyecto está todo super explicado, pero la idea base es que con PyEmpaq se puede meter todo el proyecto (código fuente, imágenes necesarias, etc.) en un sólo archivo .pyz, que termina siendo el único archivo que hay que distribuir.

Exactamente como vemos en este videito:

Luego, la persona que recibe o se baja ese archivo, lo único que tiene que hacer es ejecutarlo con Python. La magia de PyEmpaq hará que (la primera vez solamente) ese archivo se expanda en algún lugar piola, se instalen las dependencias necesarias, y finalmente se ejecute el programa indicado.

Lo podemos ver en este otro videito:

Es muy multiplataforma: se puede empaquetar estando en Linux, Mac o Windows, y ese .pyz resultante funcionará sin problema en esos sistemas operativos. Incluso cruzándolos: podemos empaquetar en Linux y ejecutarlo en Windows, etc.

Para mostrar todo el potencial, armé tres ejemplitos para que cualquiera pueda probar que el empaquetado funciona:

en una terminal: un ejemplo muy chiquito que corre sólo en la terminal
un juego: un juego simple usando la biblioteca Arcade de Python (en realidad es el ejemplo 6 de su tutorial)
una aplicación de escritorio: un aplicación completa de escritorio usando el framework PyQt5 (es mi programa Encuentro)

Como pueden ver en los issues le falta bastante laburo para que se lo pueda considerar "estable", pero ya llegará. Por lo pronto lo voy a llevar al PyCamp de Noviembre.

Distribuyendo Encuentro

Facundo Batista — Sun, 08 Aug 2021 16:19:00 GMT

El año pasado les contaba que con la ayuda de un colaborador sacamos a flote y renovamos totalmente Encuentro.

Eso quedó ahí, y aunque se podía clonar el proyecto o bajar un tarball y usarlo sin problema, realmente no había armado nada para que sea facil distribuirlo. Y es que poder distribuirlo y que se pueda usar facilmente es un laburo necesario para que todes puedan realmente aprovechar el programa.

En su momento, aprovechando que laburé para armar un instalador de Windows de TypusPocus, armé también el instalador para Windows de Encuentro.

¿Pero y los linuxes? Bueno, no es tan fácil. Armar un .deb o un .rpm no es trivial (y sólo se cubre Debian, Ubuntu, Fedora, y algunos derivados). Y para Arch es distinto. Traté de armar un snap, que funca en muchos linuxes, pero como es un formato que tiene "todo adentro y listo para usar" no es sencillo meter cosas gigantes del escritorio, como PyQt5. Y sí, claro, siempre te podés bajar el tarball o clonar el proyecto y usar Encuentro en Linux, pero no es sencillo, termina siendo una barrera.

Por otro lado, desde hace algunos meses empezó a germinar en mi cabeza una idea para distribuir proyectos Python, y hace algunas semanas empezó a catalizarse en algo firme, posible. Lo dí por llamar PyEmpaq y todavía está muy verde (ya escribiré un post cuando esté más firme).

El punto es que justamente PyEmpaq me permite distribuir Encuentro de forma sencilla :). Es sólo un archivo, te lo bajás y lo corrés con Python 3, y listo. Sí, tenés que tener Python instalado en la máquina, pero eso siempre se cumple con los Linuxes. ¡Y nada más!

La primera vez va a tardar un toque porque arma el entorno para que el programa corra ok, pero luego lo reusa y listo. Y no es un instalador: vas a tener que volver a correrlo desde la terminal cada vez que lo quieras usar (¿les dije que estaba verde?).

Pero funciona, y es suficiente para que sea usable. Así que actualicé la página de Encuentro para reflejar estas dos formas de instalación/uso, y listo.

Que lo aprovechen.

Distribución de teclado

Facundo Batista — Mon, 23 Oct 2017 22:13:48 GMT

Arranquemos la historia a principios de siglo, porque en algún momento hay que arrancarla.

Mi computadora principal hogareña tenía un teclado con distribución "en español" (lo que normalmente se consigue en las casas de computación), pero en el laburo que arranqué en el 2000 (Unifón) todas las computadoras tenían distribución "latinoamericana" (que es lo que venden las marcas grandes, como IBM, Dell, etc, en toda Latinoamérica).

Los teclados eran diferentes, sí, pero no tanto. Encima alrededor del 2004 decidí comprarme un teclado de buena calidad, y elegí uno marca IBM, como los de la oficina, que me gustaban mucho. Obviamente, era distribución latinoamericana.

Desde ese momento usé esa distribución exclusivamente.

La laptop que usaba los últimos meses de Movistar, la que me dieron en Cyclelogic (una Dell Inspiron), y la que me dieron en Ericsson (creo que una HP) todas eran compradas acá así que eran todas con teclado latinoamericano.

Cuando entré en Canonical, me compré una laptop yo. En ese momento compré en Argentina una Dell XPS m1330, muy linda máquina. Al momento de renovarla busqué mucho y terminé en una Samsung que nunca me convenció mucho, también comprada acá. En ambos casos, teclado latinoamericano.

Y mientras tanto, seguía usando en la desktop el excelente teclado IBM que me había comprado hace tanto tiempo.

El año pasado volvía a renovar la laptop, y luego de buscar varios meses algo que me convenciera acá en Argentina, en Chile o en Uruguay, terminé tomando la decisión de comprarla en USA (una Lenovo Thinkpad). Claro, con teclado en inglés, pero mi idea era luego comprar el teclado acá y cambiárselo.

Muchas personas (desde hace mucho tiempo) me preguntaban por qué no usaba teclado en inglés y listo. Puedo agrupar toda esa gente en dos grandes grupos:

los que usan el teclado en inglés configurado como "inglés", sin acentos ni eñe, pero escriben todo el tiempo con faltas de ortografía; esto es llanamente inaceptable para mí.
los que usan el teclado en inglés configurado como "internacional con teclas muertas" (que era como yo tenía la laptop nueva), donde para poner un acento hay que teclear el tilde y luego la vocal; el problema de esto es que para escribir el tilde sólo, hay que teclear el tilde y luego espacio (y como es la misma tecla, para comillas hay que hacer shift+tilde y luego espacio). Funciona, pero es tremendamente ineficiente y molesto.

El 2017 me encontró con el mismatch de teclado entre el desktop y la laptop, algo que me molestaba bastante. Y en Agosto pasaron dos cosas.

Por un lado ya me había cansado de esperar que Lenovo Argentina me vendiera un teclado en latinoamericano para la laptop. Nunca lo importaron, siempre me lo patearon para adelante, ¡durante un año!

Por otro lado, Joac me mostró que hay una configuración "internacional con teclas muertas por AltGr", que lo que hace es evitar el "doble tecleo": para poner una á, sólo hay que hacer AltGr+a. Y listo. Tilde es tilde, comilla es comilla, etc. Hay casos donde necesitamos componer caracteres con varias teclas, pero no es frecuente (por ejemplo, si queremos escribir una ü, donde ahí si tenemos que teclear AltGr+shift+tilde, y luego la u).

Esta configuración me resultó bastante funcional (aunque no ideal), así que lo que tenía que hacer también era solucionar el mismatch con la desktop, por lo que me compré en el último viaje un teclado Lenovo que es igualito al IBM que tenía... pero en inglés.

Así que acá me ven, a la vejez viruela, etc, etc.

La CDPedia en Educ.ar

Facundo Batista — Tue, 20 Dec 2011 23:35:31 GMT

¡Finalmente! Luego de varios meses de discutir, pelear diseños, frases que debían aparecer en las cajas y en lo impreso del CD, y varios etcéteras más, aparecieron las cajas de Educ.ar.

Todavía no me queda claro si ya se enviaron y llegaron a las escuelas de todo el país, ya se enviaron y van a ir llegando en las sucesivas semanas, o se va a mandar a principios del año que viene... pero bueno, a nosotros ya nos dieron unos ejemplos del producto final.

Como ven en la foto, tenemos un pack para nivel medio y otro para nivel superior. En ambos casos se incluye un CD que es "la wikipedia en el aula". Aunque la caja y los discos tienen mucho de lo que les obligamos a poner (las licencias correspondientes, o la leyenda "se permite la copia y distribución de este disco" bien legible, por ejemplo), ni esa caja ni el disco tienen los logos de PyAr ni de Wikipedia. Una lástima.

Por otro lado, también hicieron cajitas separadas con la "wikipedia en el aula", y para esos sí: está el logo de PyAr en el reverso, y el disco, y la URL de la CDPedia en el frente, bien grande.

No está mal, en general, pero jode porque ellos NO cumplieron con lo prometido, :(

En fin, de a poquito.