# Vers une étude reproductible : la réalité du terrain

On m'annonce déjà 3 enfers !
- pb concrets en matière de données : volume, hétérogénéité, temporalité, formats...
- défis logiciels : taille (le document computationnel ne suffit plus), vieillissement
- calcul numérique : les bizarreries, parallélisation, hasard...

# l'enfer des données

"Vraies" données = "diverses"

En gros, le tabulaire est une lointaine utopie.

\+ problème de la taille des données...

Il faudra transformer des formats textes (lisibles, cool) en binaires, moins lourds.
Mais il faut garder les méta-données !

(Petit-boutisme / gros-boutisme : même le binaire pour les nb manque de conventions !)

## Format binaires généraux 

Pour avoir ce minimum de convention qui permet d'avoir des méta-données

**FITS** (flexible image transport sys)

Créé et mis à jour par des astrophysicien, mais bibli vaticane.
H/DU : header unit & data unit
Le header est un dico. Le contenu, du binaire ou du txt.
PyFITS package


**HDF5** (hierarchical data format)

~Arborescence de fichiers.
Group = répertoire, contenant des datasets ou d'autres groups.
Pas de structure imposée pour les méta-données ou le contenu.

Comme c'est plus général, plus complexe à utiliser.
Voir h5py.

## Stockage ?

Les git- hub/lab ne sont pas adaptés.
Voir dans son labo (~dropbox).

Zenodo (~CERN) ou FigShare (privé, ~open science, mais trop peu souverain pour moi, patron anglais)


# Enfer logiciel

## Le code...
L'enfer vient souvent de passages à l'échelle pas anticipés.
Plus de 3/4 pages de notebook, c'est trop.

Orgmode peut aider, mais on restera sur du linéaire.

Utiliser un **workflow** ?
Pour faire de l'encapsulation, pour connecter les fonctions 
(le moteur d'execution se charge du côté opérationnel).

Ça n'empêche pas le code de devenir complexe, hein, mais la vue en graphe reste vertueuse.
(Ça va aussi aider si j'ai plusieurs langages !)

Le notebook est un workflow séquentiel, en un sens 
(avec des risques si éxécute pas dans l'ordre)...
Mais il est plus riche sur la possibilité de narration.

Un "makefile" est aussi une forme de workflow rudimentaire.

Pour les trucs légers (pas conçu pour paralléliser), voir :
[dask](https://examples.dask.org/applications/prefect-etl.html), drake, swift, snakemake...
En plus lourd, voir VisTrail ou Collective Knowledge, par exemple.

Gros calculs : fonctionner par checkpoints et par cache.
(J'ai l'expérience...)

## L'environnement

(Nous montre un très beau graphe des dépendances derrière matplotlib...)
Question des "versions" originales des lib, et des "distributions"...

Pour contrôler mon environnement, il serait bon que j'ai un docker 
(moins lourd qu'une vraie VM).

Je peux faire des "images" de mon bazar. (Et surveiller ensuite !)

Je peux aussi faire le ménage : environnement neuf (docker), 
et expliciter la recette de constitution de l'environnement.

## et dans la durée...

Changement des couleurs par défaut de matplotlib, l'angoisse !
(Des exemples plus grave, avec des analyses qui sont différentes sur de la grosse science,
quand on bouge d'une version de mac à l'autre, ou vers PC.)

"Outil à dvt rapide" : prototypes rapides, mais ces outils sont aussi peu pérennes.
Les bugs disparaissent ***et apparaissent*** vite.

Méthodo d'intégration continue, certes (tests de non-régression).
À utiliser dans la recherche ? 
(Lol, l'initiative [Popper]https://falsifiable.us/) dont les dernières news datent de 2019.)

Le C serait plus maitrisable, en recodant tout...
Compromis entre "modernisme" et pérrenité.

Mais pour l'archivage, github, gitlab, est-ce si pérenne ?
Bref, **software heritage** pourrait être plus sûr.
(Sinon, HAL permet de déposer du code, d'autant qu'ils s'occupent de relier.)

Mais ajd, pas sûr qu'on ait des solutions pérennes d'archivages et de gestion des envs...
On fait au best effort, donc.

(Visiblement, lister les versions de bibliothèques chargées ne suffit pas.)
(Ils ne recommandent pas dropbox.)