Gestor de paquetes Spack

Spack es otro de los gestores de paquetes modernos que es considerado como una buena alternativa. Está escrito en Python, gracias a su flexibilidad ha tenido un creciente uso en HPC. Al igual que los sistemas anteriores, Spack es compatible con un número arbitrario de las instalaciones de software, y como Nix puede identificarlos con los hashes. A diferencia de cualquier sistema anterior, Spack proporciona un lenguaje conciso para especificar y administrar el espacio combinatorio de configuraciones de software de HPC. Spack ofrece las siguientes características únicas:

1. Paquetes componibles, explícitamente parametrizados por la versión, plataforma, compilador, las opciones y dependencias.

2. Una sintaxis novedosa de especificación recursiva para el grafo de dependencia y limitaciones, que ayuda en la gestión de la construcción del espacio de parámetros. 3. Dependencias versionadas virtuales para manejar versionadas, incompatible ABI

interfaces como MPI.

4. Un nuevo proceso de concretización que traduce una especificación de compilación abstracta en una especificación de compilación completa y concreta.

5. Un entorno de compilación que utiliza contenedores de compilador para hacer cumplir la consistencia de compilación y simplificar la escritura de paquetes.

Estructura de Spack

En Spack, los packages son scripts de Python, estos son los que compilan los softwares. Cada

packages es una clase que se hereda de la clase base Package, esta implementa la mayor parte del proceso de compilación, pero las subclases proporcionan sus propios métodos de instalación para manejar los detalles de los paquetes particulares. La subclase no tiene que gestionar la ubicación de la instalación. Más bien, Spack pasa al método de instalar un parámetro prefix donde contiene la ubicación. El implementador de un package debe asegurarse de que la función de instalación instale el paquete en prefix, y Spack asegura que el prefix se calcula de manera única para todas las configuraciones de un package. Para simplificar la implementación de pakcages aún más, Spack incorpora un lenguaje de dominio

específico (DSL). El DSL proporciona directivas, como depends_on, version, patch y

provides, que añade metadatos a la clase package.

Spack llama spec (especificación) a una única configuración de compilación. Spack comunica las dependencias y parámetros con el package principal utilizando el argumento

spec en el método de instalación. Spack resuelve las dependencias debido a los parámetros

depen_on especificados en los packages y crea recursivamente un grafo acíclico que en caso que el usuario no use ningún spec en la línea de comando, el grafo será un grafo completo donde Spack tendrá libertad cuando compile el paquete en cuantos a especificaciones de compilación, versiones, entre otros. También los spec no solo pueden ser definidos por el usuario en la línea de comandos, un software determinado puede tener como dependencia un paquete de una versión específica, en estos casos el propio archivo package que da soporte a la aplicación debe contener en sus parámetros de dependencia la spec de la versión que necesita y así Spack instalará previamente el paquete correcto.

En este, el grafo de dependencia es abstracto, ya que podría describir más de una configuración de software y por lo tanto Spack aún con este no sería capaz de instalar lo que el usuario exactamente quiere. Antes de que Spack compile un spec, se debe garantizar las siguientes condiciones:

1. En el grafo spec (grafo completo) ningún paquete de dependencia debe faltar; 2. En el grafo spec (grafo completo) ningún paquete debe ser virtual;

3. Todos los parámetros deben estar establecidos para todos los paquetes en el grafo. Si la spec cumple con estos criterios, entonces ya no sería abstracto sino concreto. La concretización es el componente central del proceso de compilación de Spack que le permite reducir una descripción abstracta sin restricciones a una compilación concreta. Eso Spack lo resuelve con un algoritmo de concretización.

Entorno aislado

Spack establece PATH, PKG_CONFIG_PATH, CMAKE_PREFIX_PATH, y LD_LIBRARY_PATH para incluir las dependencias de la compilación que realiza. Otros sistemas de compilación utilizan comúnmente estas variables para ubicar dependencias, y el establecimiento les ayuda a asegurar que se detectan las bibliotecas correctas.

Spack gestiona RPATHs y otras políticas de compilación con compiler wrappers

(contenedores de compilador). En cada entorno aislado de instalación, Spack establece las variables de entorno CC, CXX, F77, y FC para apuntar a sus scripts de contenedores de compilador. Estas variables son usadas por la mayoría de los compiladores del sistema para seleccionar compiladores C, C++ y Fortran, por lo que normalmente son captadas de forma automática. Cuando se ejecuta, los contenedores insertan banderas include (-I), library (-L), y RPATH (-Wl, -rpath o similar) en la lista de argumentos. Estos apuntan a los directorios

include y lib de las instalaciones de dependencia, donde se encuentran las headers (cabeceras) y bibliotecas necesarias. Los contenedores invocan el compilador real con los argumentos modificados. Esto causa que los contenedores de compilador de Spack incurran en una pequeña pero notable sobrecarga de rendimiento.

Además de gestionar el entorno de tiempo de compilación, Spack puede ayudar en la gestión del entorno de tiempo de ejecución. Un paquete puede necesitar como variables de entorno PATH, MANPATH o PKG_CONFIG_PATH establecidas antes de que pueda ser utilizado. Muchos sitios se basan en módulos de entorno para configurar el entorno de tiempo de ejecución. Spack puede crear automáticamente simples dotkit [6] y los archivos de configuración del módulo para sus paquetes, lo que permite a los usuarios configurar su entorno de tiempo de ejecución utilizando sistemas conocidos. Mientras que los paquetes Spack no necesitan LD_LIBRARY_PATH para funcionar, se establecen en los archivos de los módulos generados, para que puedan ser utilizados por los sistemas de compilación para encontrar las bibliotecas, y también por los paquetes dependientes que no utilizan RPATH. Las futuras versiones de Spack también podrán permitir la creación de jerarquías Lmod [26]. Spack como filosofía gestiona muchas versiones diferentes de paquetes con facilidad, pero también proporciona un conjunto de referencias de extensiones sin necesidad de la configuración del entorno. Para apoyar este modo de operación, se añadió a Spack el concepto de paquetes de extensión. Módulos de Python utilizan la directiva extends(‘python’) en lugar de depends_on(‘python’). Cada módulo se instala en su propio prefijo de paquete como cualquier otro, y cada módulo depende de una instalación de Python en particular. Sin embargo, las extensiones pueden ser activadas o desactivadas dentro de la instalación de Python dependiente. La operación de activación vincula simbólicamente cada archivo en el prefix de extensión en el prefix de instalación de Python, como si este fuera instalado

directamente. Si ocurre un conflicto de archivo en esta operación, la operación de activación falla. Del mismo modo, la operación de desactivación elimina los enlaces simbólicos y restaura la instalación de Python a su estado prístino. En Spack los paquetes extensibles, como Python, pueden suministrar el código personalizado en el archivo de paquete que se especializa en activar y desactivar para el paquete en particular. Para Python, esta característica fusiona archivos en conflicto durante la activación [19].