D'où je parle

• Ingénieur de recherche, expert en calcul scientifique* spécialisé en mathématiques appliquées, responsable d'équipe support/accompagnement...
• ...travaillant à l'UAR GRICAD, basée à Grenoble, fournissant services, infrastructures et expertise en soutien à toutes les communautés de recherche grenobloises autour du calcul scientifique, du développement logiciel et de la gestion des données de la recherche.
• Je ne suis pas...
  • ...un ASR
  • ...un chercheur en informatique

* Anciennement ?

À propos de nos serveurs de calculs

• Centre de calcul avec 3 calculateurs reliés entre eux par une grille
• Environnements logiciels déployés avec guix...
• ...directement accessible aux utilisateurs (pas de module)

Les besoins

• guix: battery-included...
• Mais pas complètement chargée : nécessité de faire des paquets
  • Logiciels pas encore empaquetés (il y en a !)
  • Besoins spécifiques de versions, d'options de compilations, etc

Les forces en présence

• Quelques centaines d'utilisateurs uniques par an
• Entre 3 et 4 IT à 10% de leur temps pour l'empaquetage guix*
• Toutes les communautés et les besoins logiciels associés :
  • HPC traditionnel**
  • Workflows python, R
  • IA
  • Codes communautaires
  • etc.

* : estimation grossière
** : ne signifie pas logiciels simples à empaqueter

Les prérequis

• Les besoins des utilisateurs
• Un plateforme de développement
  • Sa propre station de travail (si GNU/Linux)
  • Un serveur dédié (VM Openstack)
  • Virtualisation*
• Un IDE. Personnellement :
  • Principalement VSCode
  • vim occasionnellement

* : travaillant sous mac, j'utilise aussi une VM Debian

Pourquoi et comment VSCode ?

• Accessible (premier pas et personnalisation)
• Directement implémenté*:
  • Édition sur serveur distant
  • Gestion de versions pratique (indice visuel, UI)
  • Les espaces de travail
  • Les snippets
• Les extensions pour coder en Guile

* : dispo aussi dans d'autres éditeurs

Workflow de développement

guix installé par dessus un OS GNU/Linux

• On édite le code du paquet
• On le build sur la machine de développement
• Quand ça semble OK, on passe à l'étape suivante

Les channels guix

• Channel : dépôt de paquets Guix
  • dépôt git
  • avec fichiers de configurations
• Le channel principal guix : 20 000 paquets
• Un utilisateur de guix peut accéder aux channels qu'il souhaite
• GRICAD a son channel

Comment faire un channel guix ?

• On créée un dépôt git accessible publiquement contenant nos définitions
• C'est tout ! (modulo quelques règles dans la création des modules)
• Remarques :
  • Toujours préférable de faire remonter les paquets upstream (accès pour tous, contrôle qualité, substitutes, etc.)
  • Le mainteneur du channel a la responsabilité de ses paquets !

Comment un utilisateur accède à un channel ?

Il créée un fichier $HOME/.config/guix/channels.scmoù il peut lister les channels auxquels il veut accéder :

(list %default-guix-channel
    (channel
        (name 'guix-science)
        (url "https://github.com/guix-science/guix-science")
        (introduction
         (make-channel-introduction
          "b1fe5aaff3ab48e798a4cce02f0212bc91f423dc"
          (openpgp-fingerprint
           "CA4F 8CF4 37D7 478F DA05  5FD4 4213 7701 1A37 8446"))))
    (channel
        (name 'guix-cran)
        (url "https://github.com/guix-science/guix-cran"))
    (channel
        (name 'gricad-guix-packages)
        (url "https://gricad-gitlab.univ-grenoble-alpes.fr/bouttiep/gricad_guix_packages.git")
        (branch "master")))

Workflow de développement

1. On édite le code du paquet sur la plateforme de développement
2. On le build sur la machine de développement. Si NOK, retour au 1. Sinon 3.
3. On passe sur le dépôt git du channel GRICAD
4. On créée une nouvelle branche
5. On commit le code du paquet dans cette branche
6. On l'installe depuis une machine guix (plat. dev., clusters) avec ce channel positionné sur cette branche
   1. Si NOK, retour au 5.
   2. Si OK, GOTO 7.
7. On merge la branche de développement sur la branche main (ou master)

La structure du channel

• Homogénéisation du nom du channel avec d'autres channels existants (nomenclature CC ?)
• Actuellement, deux répertoires :
  • common, nonfree
  • Peut mieux faire avec par exemple gricad common, gricad python, gricad nonfree etc.
• Découpage des modules à revoir
• .guix-authorizations, .guix-channels ?

La qualité des paquets

• La plupart des paquets GRICAD ont été faits en même temps que l'on montait en compétence
  • Désactivation fréquente des tests au build
  • Pas de remontée upstream: timidité, manque de temps, etc.
  • Pas d'intégration continue pour tester la compatibilité avec les évolutions des autres channels*
  • Pas de substituts !

* 3 cas en 3 ans

Rationalisation des paquets

Aiguiller les paquets du channels GRICAD ?

• Remontée upstream ?
• guix-science ?
• Reste une partie qui doit rester dans le channel gricad