On m'a déjà "vendu" Nix une fois que c'était génial et tout et tout...
Si si c'est génial !! Enfin le changement de paradigme (approche déclarative et fonctionnelle) est vraiment très intéressant.
Déjà, nix n'est pas toujours compatible avec lui même selon les versions donc l'environnement stable sur un cluster qui évolue et se renouvelle
Je n'ai pas compris ?
Sinon, un point d'entrée concernant GNU Guix et le HPC est ce papier par les mainteneurs même si des petites choses se sont améliorées depuis.
On a toujours le même environnement... ce qui permet la reproductibilité. C'est un argument actuel en science. [...] autant je suis sceptique en science pour du code ou ce mot, reproductible, est utilisé pour complètement autre chose.
Effectivement, le terme Reproducible Science est souvent utilisé sans vraiment définir de quoi on parle. N'est-ce pas un peu comme Big Data ou Machine Learning ? ;-)
Disons pour faire simple et rapide, il faut distinguer :
répétable : le même code a tourné (plusieurs fois?) avec les mêmes données sur la même machine et les résultats sont similaires ;
reproductible : le même code a tourné avec les mêmes données sur une autre machine et les résultats sont similaires ;
réplicable : un autre code a tourné avec les mêmes données sur une autre machine et les résultats sont similaires.
Bon il faut aussi définir similaire. Quelle précision ? Arithmétique d'intervalle ? etc.
Disons que la distinction entre les 3 niveaux est admise mais la définition ne l'est pas toujours. Voir par exemple le journal ReScience.
Retrouver N fois le même résultat avec le même code n'a pas un intérêt fou, sauf à vérifier que le chercheur n'a pas triché, et encore...
N'est-ce pas essentiel dans le processus de revue par les pairs ?
En plus, ce coté reproductible pousse les personnes à faire du code non portable, aux API qui changent et dont le résultat est fortement dépendant des versions des modules de ceci et de cela. Telle et telle version marchent (même s'il y a un bogue et que c'est hyper dépendant des versions), hop je publie -> c'est reproductible par tout lecteur !
Je ne suis pas sûr de saisir la signification.
Parce que non ! Ce n'est pas reproductible par tout lecteur parce que justement c'est généralement hyper dépendant des versions et que cela fonctionne uniquement avec telle et telle version.
Il faut peut-être distinguer le champ d'application. Dans un contexte simulation, pour faire simple, on résout une équation (ou plusieurs) et en général c'est un gros code monolithique ; ou alors il y a un nombre de dépendances résonnables, dans le sens où même si c'est fastidieux, toutes les dépendances peuvent être installés à la main.
Dans d'autres contextes, ce sont des dizaines de "petits" codes qui interagissent entre eux (workflow ou pipeline) et chaque code a lui-même des dépendances et parfois 2 petits codes dépendent d'une même bibliothèque mais dans une version différente. Et parfois il y a des subtilités difficiles à trouver. Qui n'a pas passé des heures à chercher pourquoi cela fonctionne sur telle machine et pas sur telle autre alors que diantre! tout est pourtant identique... :-)
Il y a une notion peu mise en avant dans la reproductibilité, c'est la pérennité dans le temps. Comment s'assurer que ce que je publie aujourd'hui et que je ne maintiendrai probablement pas parce que le chercheur n'a pas forcément le temps, que mon code puisse être utilisable dans quelques mois ou années alors que tout un tas de bibliothèques aura évolué.
Disons qu'aujourd'hui, je dispose d'un code publié et open source qui dépend d'une dizaine de bibliothèques elles aussi open source. Disons que ce code a été écrit il y a 2 ans, il est en Python et dépend de bibliothèques en C, Fortran, C++ (de différentes saveurs) etc. qui ont toutes évoluées et dont l'API est devenu incompatible. Comment faire ?
Soit j'essaie de mettre à jour le code Python. Mais quel travail, surtout s'il a été écrit par un autre ou un étudiant, s'il n'est pas ou peu documenté, etc.
Soit j'arrive à retrouver toutes les versions utilisées des composants et à tout compiler. Mais encore quel travail.
Et au final, je ne trouve pas le même résultat que celui dans l'article. Est-ce que l'auteur s'est trompé ? a triché ? Ai-je fait une erreur dans la mise à jour ou est-ce vraiment la bonne version de la bibliothèque ? etc.
La Science est basée sur la vérification et comment vérifier ?
En clair, pour qu'il y ait reproductibilité, il faut qu'un déploiement soit possible dans le temps.
Or aujourd'hui, seule une solution pour la partie déploiement est proposée avec les conteneurs. Mais par exemple les Dockerfiles ne permettent pas une pérennité dans le temps. Par exemple avec Debian, est-ce que les binaires qu'apt-get tirent sont boostrappables ? Comment reconstruire aujourd'hui le même binaire présent dans l'archive en mai 2018 ? etc.
Pour le dire clairement, à mon sens, les solutions comme Docker ne tendent pas vers une démarche scientifique.
Pour schématiser, GNU Guix est peut-être l'outil le plus avancé pour la reproductibilité computationnelle en science.
1.
Il permet totalement de capturer un environnement avec guix describe. Par exemple :
où guix est le dépôt (channel) "officiel" et bimsb est un dépôt local (qui pourrait aussi être sur une forge) qui me sert à tester (par exemple pour empaquetter des choses en R de BioConductor).
2.
Il permet de créer des environnements (comme virtualenv) très facilement. Par exemple :
créé un environnement isolé avec Emacs, GCC, Python et Numpy. Prêt pour travailler ! ;-)
3.
Il permet le déploiement facilement avec guix pack. Cela crée un fichier .tar.gz avec tous les binaires. Et il y a même une option pour générer une image Docker. Quelques explications sur le blog de GuixHPC.
4.
Il permet de restaurer un état antérieur du dépôt, par exemple au 1er mai 2018, avec guix pull --commit=bb6f94c71e. Maintenant, guix package -i emacs installera Emacs et ses dépendances exactement comme je l'aurais fait ce 1er mai 2018.
A ma connaissance, les channels ne sont pas encore supportés dans ce mécanisme... Un patch à proposer? :-)
Évidemment, il y a la possibilité d'utiliser des fichiers manifest. Plus d'explications sur guix pull c'est par là.
Qu'en est-il du Python ? Car en pratique, c'est souvent les modules Python qui sont "chiants" à packager vu que cela bouge tout le temps (trop souvent) et que les API changent... Avec Nix, mes amis font du conda ou du virtualenv... Bref, c'est pas une super réussite !
Même si guix import pypi fait une bonne partie du boulot, ce n'est pas forcément facile de suivre. Cela n'a pas à voir avec le gestionnaire de paquet mais avec la communauté. Pas assez de bras, pas de chocolat.
Si le paquet est déjà dans GNU Guix mais pas à la bonne version, en général il suffit de mettre à jour le numéro de version et le hash upstream, et puis guix build pour vérifier et voilà guix package -i. Les channels facilitent vraiment cela.
Si le paquet n'est pas dans GNU Guix, cela devient un boulot d'empaquetage. Et même si c'est assez facile avec GNU Guix---une fois passé la barrière psychologique des parenthèses ; je trouve que c'est plus facile que de faire un paquet Conda---cela reste un boulot d'empaquetage avec les trucs pénibles (quelque soit le gestionnaire de paquet).
[^] # Re: Nix et autres
Posté par zimoun . En réponse à la dépêche GNU Guix version Un‐Point‐Zéro. Évalué à 5.
Si si c'est génial !! Enfin le changement de paradigme (approche déclarative et fonctionnelle) est vraiment très intéressant.
Je n'ai pas compris ?
Sinon, un point d'entrée concernant GNU Guix et le HPC est ce papier par les mainteneurs même si des petites choses se sont améliorées depuis.
Effectivement, le terme Reproducible Science est souvent utilisé sans vraiment définir de quoi on parle. N'est-ce pas un peu comme Big Data ou Machine Learning ? ;-)
Disons pour faire simple et rapide, il faut distinguer :
Bon il faut aussi définir similaire. Quelle précision ? Arithmétique d'intervalle ? etc.
Disons que la distinction entre les 3 niveaux est admise mais la définition ne l'est pas toujours. Voir par exemple le journal ReScience.
N'est-ce pas essentiel dans le processus de revue par les pairs ?
Je ne suis pas sûr de saisir la signification.
Parce que non ! Ce n'est pas reproductible par tout lecteur parce que justement c'est généralement hyper dépendant des versions et que cela fonctionne uniquement avec telle et telle version.
Il faut peut-être distinguer le champ d'application. Dans un contexte simulation, pour faire simple, on résout une équation (ou plusieurs) et en général c'est un gros code monolithique ; ou alors il y a un nombre de dépendances résonnables, dans le sens où même si c'est fastidieux, toutes les dépendances peuvent être installés à la main.
Dans d'autres contextes, ce sont des dizaines de "petits" codes qui interagissent entre eux (workflow ou pipeline) et chaque code a lui-même des dépendances et parfois 2 petits codes dépendent d'une même bibliothèque mais dans une version différente. Et parfois il y a des subtilités difficiles à trouver. Qui n'a pas passé des heures à chercher pourquoi cela fonctionne sur telle machine et pas sur telle autre alors que diantre! tout est pourtant identique... :-)
Il y a une notion peu mise en avant dans la reproductibilité, c'est la pérennité dans le temps. Comment s'assurer que ce que je publie aujourd'hui et que je ne maintiendrai probablement pas parce que le chercheur n'a pas forcément le temps, que mon code puisse être utilisable dans quelques mois ou années alors que tout un tas de bibliothèques aura évolué.
Disons qu'aujourd'hui, je dispose d'un code publié et open source qui dépend d'une dizaine de bibliothèques elles aussi open source. Disons que ce code a été écrit il y a 2 ans, il est en Python et dépend de bibliothèques en C, Fortran, C++ (de différentes saveurs) etc. qui ont toutes évoluées et dont l'API est devenu incompatible. Comment faire ?
Et au final, je ne trouve pas le même résultat que celui dans l'article. Est-ce que l'auteur s'est trompé ? a triché ? Ai-je fait une erreur dans la mise à jour ou est-ce vraiment la bonne version de la bibliothèque ? etc.
La Science est basée sur la vérification et comment vérifier ?
En clair, pour qu'il y ait reproductibilité, il faut qu'un déploiement soit possible dans le temps.
Or aujourd'hui, seule une solution pour la partie déploiement est proposée avec les conteneurs. Mais par exemple les
Dockerfilesne permettent pas une pérennité dans le temps. Par exemple avec Debian, est-ce que les binaires qu'apt-gettirent sont boostrappables ? Comment reconstruire aujourd'hui le même binaire présent dans l'archive en mai 2018 ? etc.Pour le dire clairement, à mon sens, les solutions comme Docker ne tendent pas vers une démarche scientifique.
Pour schématiser, GNU Guix est peut-être l'outil le plus avancé pour la reproductibilité computationnelle en science.
1.
Il permet totalement de capturer un environnement avec
guix describe. Par exemple :où
guixest le dépôt (channel) "officiel" etbimsbest un dépôt local (qui pourrait aussi être sur une forge) qui me sert à tester (par exemple pour empaquetter des choses en R de BioConductor).2.
Il permet de créer des environnements (comme virtualenv) très facilement. Par exemple :
créé un environnement isolé avec Emacs, GCC, Python et Numpy. Prêt pour travailler ! ;-)
3.
Il permet le déploiement facilement avec
guix pack. Cela crée un fichier.tar.gzavec tous les binaires. Et il y a même une option pour générer une image Docker. Quelques explications sur le blog de GuixHPC.4.
Il permet de restaurer un état antérieur du dépôt, par exemple au 1er mai 2018, avec
guix pull --commit=bb6f94c71e. Maintenant,guix package -i emacsinstallera Emacs et ses dépendances exactement comme je l'aurais fait ce 1er mai 2018.A ma connaissance, les channels ne sont pas encore supportés dans ce mécanisme... Un patch à proposer? :-)
Évidemment, il y a la possibilité d'utiliser des fichiers manifest. Plus d'explications sur
guix pullc'est par là.Même si
guix import pypifait une bonne partie du boulot, ce n'est pas forcément facile de suivre. Cela n'a pas à voir avec le gestionnaire de paquet mais avec la communauté. Pas assez de bras, pas de chocolat.Si le paquet est déjà dans GNU Guix mais pas à la bonne version, en général il suffit de mettre à jour le numéro de version et le hash upstream, et puis
guix buildpour vérifier et voilàguix package -i. Les channels facilitent vraiment cela.Si le paquet n'est pas dans GNU Guix, cela devient un boulot d'empaquetage. Et même si c'est assez facile avec GNU Guix---une fois passé la barrière psychologique des parenthèses ; je trouve que c'est plus facile que de faire un paquet Conda---cela reste un boulot d'empaquetage avec les trucs pénibles (quelque soit le gestionnaire de paquet).