PackageMaker v3.2.7: cómo crear y distribuir aplicaciones Python como .iflapp

Las aplicaciones Python suelen necesitar algo más que un script ejecutable para poder distribuirse de forma consistente. Hay que conservar metadatos, recursos, iconos, configuraciones, actualizadores y una estructura reconocible por el ecosistema de destino. Influent PackageMaker aborda ese problema mediante un flujo de trabajo que transforma un proyecto Python en un paquete .iflapp con nombre, plataforma y versión normalizados.

El proyecto se encuentra disponible en JesusQuijada34/packagemaker, donde también se mantienen el código fuente, la documentación y las notas de lanzamiento.

La versión v3.2.7

La versión pública actual es v3.2.7-26.05-20.13. Esta actualización se concentra en mejorar la experiencia de desarrollo, la estabilidad visual y la limpieza posterior a la compilación. El detalle completo está documentado en RELEASE_NOTES.md.

Uno de los cambios más visibles es la ampliación del diálogo para abrir proyectos con editores externos. PackageMaker incorpora detección para herramientas como Zed, Fleet, Emacs, Geany, Kate y Gedit, de modo que el desarrollador pueda elegir su editor habitual sin modificar manualmente la configuración del proyecto.

También se mejoró el renderizado de iconos en Linux. La detección y conversión de iconos permite que los editores y las aplicaciones mantengan una presentación más coherente en entornos como Ubuntu. A esto se suman correcciones de estabilidad, entre ellas la resolución de un TypeError en la información de editores, el problema del fondo blanco al maximizar ventanas y la eliminación de gradientes visuales innecesarios.

¿Qué problema resuelve PackageMaker?

PackageMaker organiza un proyecto Python para que pueda compilarse y entregarse como una unidad instalable o distribuible. La estructura conserva archivos importantes como details.xml, version.res, autorun, autorun.bat, .storedetail, updater.py, config/settings.json y los marcadores estructurales del paquete.

El archivo details.xml define la identidad del proyecto. A partir de sus metadatos, PackageMaker construye nombres canónicos como:

Influent.packagemaker.v3.2.7-26.05-20.13-Danenone.iflapp
Influent.packagemaker.v3.2.7-26.05-20.13-Knosthalij.iflapp
Influent.packagemaker.v3.2.7-26.05-20.13-AlphaCube.iflapp

Los sufijos representan el destino del paquete: Danenone para Linux, Knosthalij para Windows y AlphaCube para proyectos multiplataforma. Esta convención facilita distinguir los artefactos y evita confundir un paquete Linux con uno Windows.

Cómo funciona el flujo de compilación

El proceso comienza leyendo los metadatos del proyecto y localizando el script principal junto con los scripts secundarios que deben compilarse. Después, el compilador prepara los directorios de recursos, analiza imports relevantes e incorpora los datos necesarios para que la aplicación funcione dentro del ejecutable generado.

PyInstaller se utiliza como librería embebida. En Linux, los binarios se generan sin extensión; en Windows, el mismo flujo produce ejecutables con extensión .exe. Para un proyecto AlphaCube, la compilación debe realizarse en el sistema operativo de destino, ya que un runner Linux no puede sustituir a un entorno Windows real para producir un ejecutable Windows fiable.

Durante el empaquetado, se respetan las exclusiones definidas en .gitignore. Esto evita introducir en el artefacto directorios de control de versiones, configuraciones del IDE, caches y otros archivos que no forman parte de la aplicación distribuible. Tras la compilación se eliminan los directorios temporales de PyInstaller, como build/ y dist/, además de los archivos .spec generados durante el proceso.

Finalmente, PackageMaker copia los binarios y la estructura del proyecto a un directorio temporal, actualiza el details.xml con la plataforma correspondiente y comprime el resultado como ZIP con extensión .iflapp. Antes de dar el proceso por terminado, comprueba que el archivo sea un ZIP válido y que contenga details.xml y todos los binarios esperados.

Uso desde la línea de comandos

El modo recomendado para una compilación automatizada es --buildthis. En Linux, el comando básico es:

python packagemaker.py \
  --buildthis . \
  --output ./releases \
  --platform Linux

En Windows se utiliza el mismo entrypoint, cambiando la plataforma:

python packagemaker.py --buildthis . --output .\\releases --platform Windows

La salida esperada en Windows contiene los binarios .exe dentro del paquete Knosthalij. La salida Linux utiliza el sufijo Danenone. Para conservar la reproducibilidad, conviene ejecutar cada compilación en el sistema operativo que corresponde al artefacto que se desea distribuir.

Mejoras de seguridad y mantenimiento

Las versiones recientes también incorporan medidas de mantenimiento que normalmente pasan desapercibidas hasta que aparece un problema. La extracción de archivos ZIP se realiza con validación contra rutas absolutas, separadores de Windows, secuencias .. y enlaces simbólicos peligrosos. Esto evita que un archivo comprimido pueda escribir fuera del directorio de destino durante una actualización o instalación.

El proceso de terminación del actualizador utiliza argumentos separados y evita la ejecución de comandos con shell=True. Además, la eliminación del proyecto fuente no es automática: el .iflapp debe existir, ser válido y estar fuera de la carpeta fuente, y la eliminación requiere una autorización explícita.

Estas medidas forman parte de la idea central de PackageMaker: compilar no consiste únicamente en generar un ejecutable. También implica controlar qué archivos entran en el paquete, validar el resultado y mantener el proyecto original en un estado seguro.

Compilación multiplataforma y releases

El repositorio mantiene workflows para compilación Linux, compilación Windows y creación de releases. La matriz de plataformas está configurada para que un fallo en Linux no cancele automáticamente el job Windows. Cada runner utiliza su shell nativa: Bash en Linux y PowerShell en Windows, con rutas temporales adaptadas a cada sistema.

El workflow de releases comprueba si una versión ya contiene los dos artefactos esperados. Si el release ya tiene los paquetes Danenone y Knosthalij, no vuelve a compilar ni modifica el release. Si falta uno de ellos, la lógica conserva el tag, elimina el release incompleto y lo recrea con ambos .iflapp y el contenido de RELEASE_NOTES.md.

La configuración de estos workflows puede consultarse directamente en .github/workflows. La ejecución efectiva depende de que GitHub Actions esté habilitado para la cuenta o el repositorio.

Un punto de partida para proyectos Python distribuibles

PackageMaker está pensado para quienes necesitan pasar de un conjunto de scripts a una aplicación distribuible con identidad, recursos y estructura definida. Su flujo combina PyInstaller, metadatos XML, validación de paquetes, limpieza de artefactos y soporte para distintos sistemas operativos.

La versión v3.2.7-26.05-20.13 continúa esa dirección: mejora la interacción con editores, corrige problemas visuales, refuerza la seguridad del actualizador y hace más explícito el proceso de compilación multiplataforma. Para explorar el código, consultar la estructura completa o revisar futuras actualizaciones, el punto de entrada es el repositorio oficial en GitHub.