CHESNIN Clement (010160a2) at 28 Mar 15:00
CHESNIN Clement (427de55c) at 28 Mar 15:00
.env refacto
Mikaël Salson (a6e743d6) at 27 Mar 17:46
segment.cpp: Deal with TRADV which can be tricky
... and 1 more commit
Mikaël Salson (e10aeeeb) at 27 Mar 16:48
Missing output file
Mikaël Salson (604a77ea) at 27 Mar 16:43
Store a different affect for each germline.
... and 42 more commits
Mikaël Salson (b3782ed5) at 27 Mar 16:39
Prevent inconsistent behaviour depending on locale
Extrait d'un échange avec @fthonier sur element :
Clément Chesnin
Je me demandais si on ne peut pas faire un truc plus générique dans l'appel du preprocess, mais peut-être que c'est un peu trop bourrin dans certains cas ? Ou bien avec la possibilité de désactiver le clean dans une config spécifique ?
Florian Thonier
On peut avoir un paramètre clean fournit par le serveur. Mais je ne pense pas ce soit très pertinant car a part au dev d'un preprocess, je ne vois pas pourquoi on passerait tout un serveur en "dev" pour concerver les fichiers R1/R2 ? Du coup, on peut avoir un paramètre --clean dans la ligne de commande du preprocess, ou à l'inverse, un --keep.
Clément Chesnin
OK, et du coup plutôt charge au développeur du preprocess de faire le ménage derrière lui
Pour le moment, on a un fichier .env.default et un fichier .env. Dans le fonctionnement actuel, on a plusieurs souci : le fichier .env doit nécessairement être présent (il est donc commité, mais vide) et le docker compose ne fonctionne pas bien si il n'y a pas des choses dans le .env. Ca entraine donc de devoir faire de la manutention git, ... L'idée est de simplifier ça, pour ne pas avoir de fichier à éviter dans les commit, une config par défaut facilement surchargeable, et peut-être une config dev qui existe facilement.
Après un peu de recherche, plusieurs choses :
docker-compose
à docker compose
), on peut préciser sur un env-file est required ou non (cf https://docs.docker.com/compose/environment-variables/set-environment-variables/#use-the-env_file-attribute)Dans ce cas on peut ajouter la suppression dans la script flash2.py
non ?
C'est probablement le plus propre et le plus simple.
De toute façon, pour l'utilisateur il n'y a aucun moyen d'accéder à ces fichiers et nous ils nous servent qu'en cas de problème.
Voir aussi #4776
NSX, bravo @clement.chesnin :)
Removing an user requires first to disable her/his account #5270.
Then we want to remove the data related to the account:
Discussed for vdj#1170: we may want to disable account.
At first, just setting an empty password may be enough, but a cleaner status would be better.
See also #5147
For efficient and lightweight filtering, see FiLT3r ;) https://gitlab.univ-lille.fr/filt3r/filt3r
Discuté avec Clément : si les preprocess ont fonctionné il y a peu de chance qu'on veuille retourner sur les fichiers d'origine.
Mikaël Salson (1b547f0d) at 26 Mar 10:33
Fix inverted copy