vidjil issueshttps://gitlab.inria.fr/vidjil/vidjil/-/issues2020-01-22T15:48:29+01:00https://gitlab.inria.fr/vidjil/vidjil/-/issues/3263Des analyses avec des BAM ne fonctionnent pas2020-01-22T15:48:29+01:00Thonier FlorianDes analyses avec des BAM ne fonctionnent pasJe tombe depuis quelques jours sur des bugs lors de lancement d'analyses de fichiers `BAM`.
Au début, comme il y avait des souci avec le missing id, je pensais à un lien. Il apparaît très clairement maintenant que le souci est ailleurs...Je tombe depuis quelques jours sur des bugs lors de lancement d'analyses de fichiers `BAM`.
Au début, comme il y avait des souci avec le missing id, je pensais à un lien. Il apparaît très clairement maintenant que le souci est ailleurs. En regardant le log complet de vidjil, je me rend compte qu'il est incapable de traiter le fichier :
```bash
vidjil-algo: bam.cpp:77: virtual void OnlineBAM::next(): Assertion `(bam_entry->core.flag & (1 | 64 | 128)) == 0' failed.
```
Je ne comprend pas vraiment l'erreur. Comme je n'ai pas d'autres fihciers bam en main, j'en ai téléchargé un depuis le serveur vidjil poru faire des tests. Il se trouve que sur celui-ci vidjil fonctionne parfaitement. J'ai alors pensé à des fichiers corrompus. J'ai alors voulu lancé une analyse via la commande suivante:
```bash
samtools quickcheck -v *.bam > bad_bams.fofn && echo 'all ok' || echo 'some files failed check, see bad_bams.fofn'
```
Le résultat montre que les deux fichiers (celui compatible vidjil et l'autre) sont à priori correctement formatés.
En soit, il ne semble donc pas être corrompus. Je vais quand même demander à l'utilisateur de me fournir un md5sum au cas ou. Le souci est que si l'erreur est en amont, a sa propore génération par le séquenceur, ca ne résoudra pas le souci.
en attendant, si ce n'est pas la source de l'erreur, je ne sais pas quoi faire d'autre.
@mikael\-s : Toi qui a dev la fonction pour les BAM, tu as une idée de la raison ?https://gitlab.inria.fr/vidjil/vidjil/-/issues/2344Stocker les informations de pairage des chaînes / de single cell2019-12-13T12:23:51+01:00Mikaël SalsonStocker les informations de pairage des chaînes / de single cell#2318 parle de données avec des chaînes pairées mais nous n'avons pas de moyen de conserver le pairage dans le fichier (et ensuite dans l'affichage).
Il faut donc réfléchir à la manière d'adapter le format dans ce but.
cc @magiraud#2318 parle de données avec des chaînes pairées mais nous n'avons pas de moyen de conserver le pairage dans le fichier (et ensuite dans l'affichage).
Il faut donc réfléchir à la manière d'adapter le format dans ce but.
cc @magiraudhttps://gitlab.inria.fr/vidjil/vidjil/-/issues/4099Virgule dans l'export AIRR en cas d'alternatives trouvées par IMGT/V-QUEST2019-12-10T14:09:42+01:00Mathieu GiraudVirgule dans l'export AIRR en cas d'alternatives trouvées par IMGT/V-QUESTHello @pduroux,
Parallèlement à ce que vous faites, @flothoni travaille sur l'import AIRR de plusieurs logiciels #3673, dont IMGT/V-QUEST. On voit par exemple dans une de vos sorties AIRR:
```
Homsap IGKV3-11*01 F, or Homsap IGKV3-11*02...Hello @pduroux,
Parallèlement à ce que vous faites, @flothoni travaille sur l'import AIRR de plusieurs logiciels #3673, dont IMGT/V-QUEST. On voit par exemple dans une de vos sorties AIRR:
```
Homsap IGKV3-11*01 F, or Homsap IGKV3-11*02 F or Homsap IGKV3D-11*01 F or Homsap IGKV3D-11*02 F
```
Est-ce voulu qu'il y ait une virgule `,` après le premier gène et pas ensuite ? Ou des virgules partout, sans `or`, seraient-elles plus prévisibles ?
(En interne, @flothoni garde `IGKV3-11*01` comme premier choix du V)https://gitlab.inria.fr/vidjil/vidjil/-/issues/4088Que renseigner dans le .vidjil pour que le "color by N" soit fonctionnel ?2019-12-10T10:56:36+01:00Mathieu GiraudQue renseigner dans le .vidjil pour que le "color by N" soit fonctionnel ?Question de @pduroux.
Dans `clone.js` :
```
getNlength: function () {
if (this.hasSeg('3', '5')){
return this.seg['3'].start-this.seg['5'].stop-1
```Question de @pduroux.
Dans `clone.js` :
```
getNlength: function () {
if (this.hasSeg('3', '5')){
return this.seg['3'].start-this.seg['5'].stop-1
```https://gitlab.inria.fr/vidjil/vidjil/-/issues/1048Stats sur le jeu complet dans le fichier .vidjil / smaller clones2019-10-29T14:38:34+01:00Vidjil TeamStats sur le jeu complet dans le fichier .vidjil / smaller clonesReparlé plusieurs fois lors des dernières semaines.
Quels stats seraient intéressantes, sur tous les clones (pas seulement les FineSegmentés) ? Distribution des longueurs (on l'a, mais un peu brut), autres ?
(distribution V/J/CDR3/... de...Reparlé plusieurs fois lors des dernières semaines.
Quels stats seraient intéressantes, sur tous les clones (pas seulement les FineSegmentés) ? Distribution des longueurs (on l'a, mais un peu brut), autres ?
(distribution V/J/CDR3/... demanderait de faire plus de FineSegmenter)
***
@nobodyhttps://gitlab.inria.fr/vidjil/vidjil/-/issues/1369c++: détection CDR3: Cys, Phe/Trp + séquence en AA2019-10-23T07:37:53+02:00Vidjil Teamc++: détection CDR3: Cys, Phe/Trp + séquence en AAOn aurait pu tout faire en .js, mais le but est d'avoir les infos dans le .vidjil et être aussi capable d'afficher d'autres méthodes de détection de CDR3 (Nikos ou autres).
Tout cela sera appelé à la fin, en même temps que le FineSegmen...On aurait pu tout faire en .js, mais le but est d'avoir les infos dans le .vidjil et être aussi capable d'afficher d'autres méthodes de détection de CDR3 (Nikos ou autres).
Tout cela sera appelé à la fin, en même temps que le FineSegmenter (et cela pourrait même être après le fuse, mais bon...)
***
Marc, peux-tu pousser ce que tu as fait, sur une branche séparée ? Merci.
***
merci Marc. On doit maintenant regarder (comparer miTCR ?) (IMGT ?)
Faire des should_get à partir de certaines séquences ?
On voit cela au cours du mois de mars.
***
Voir le script cdr3_detection/cdr3Finder.py fait par Florian dans la branche cdr3.
Il faudra un jour mettre tout ou partie de cela dans le C++, tout en gardant une certaine vitesse.
***
à faire, important... en avril ?
***
Pour mémoire, échange de mail avec Florian :
Le 25 févr. 2016 à 15:28, Florian Thonier <florian.thonier@inserm.fr> a écrit :
>> # Run search of cys104 & his position
>> theotical_cys104 = dataGerm[clone["seg"].get("5", 0)][312-LEN_CYS104:312].replace(".","").upper() # fix better len for cys ?
>> clone = betterFinder(portion5, borne5, theotical_cys104, clone)
> 312 : d’où vient cette valeur ? Est-ce la position exacte/approchée où on doit trouver la Cys104 dans les séquences gappées ? Ou bien la position exacte est 312 - 15 ? (et est-ce que cela marche pour tous les locus ?)
La position exacte du cys104 est de 310 à 312.
Je pars des séquences gappées pour positionné la CYS. Sans les gaps, les séquences sont de taille très diverses, et je ne peux donc plus le positionner exactement.
Normalement, le principe des gap fourni par IMGT est justement d'être extrêmement correct sur cette portion, quelques soit le locus. J'en ai regardé de visu quelques unes pour vérifier à l'époque, ils ont des erreurs sur d'autres portions où des corrections manuels pourraient probablement être apportée.
> Et avec le replace(".",""), tu n’as plus les gaps ensuite ? (Est-ce que c’était important d’avoir les gaps au départ ?)
theotical_cys104 est donc un motif de taille 15, que tu recherches de manière exacte ou approchée
Je le recherche de manière approché, en autorisant des petites modifs. De souvenir, c'est un partie un peu bancale. Je calcul un score d’occurrence en essayant de tenir compte de possible insert ou mismatch. si le score est inférieur à 12 ou 9 nt d’occurrence sur 15 ou 12 de séquence, je ne poursuit pas. (a vérifier)
C'est la partie à améliorer. Le souci, c'est que les séquences des clones , dans cette portion et dans des cas extrêmes, peuvent parfois inclure des modifications qui empêchent la détection du pattern.
Il y aurait sûrement un meilleurs moyen d'approcher le pattern.
> cysStart = cys[len(cys)-3:]
cysStart est le début de theoretical_cys104 (mais est-ce la Cys104 ou juste le début du motif de taille 15 ?)
On obtient par cette manip le codon de la cys 104 théorique de ce segment. Il existe deux codons possible pour la cys (TGT et TGC).
====
>> #looking for trp/phe codons in CDR3 seq
>> admisibleSeq = [r"FG[A-Z]G", r"WG[A-Z]G", r"^FG"]
> D’où viennent exactement ces patterns ? Le dernier n’est-il pas beaucoup plus tolérant que tous les autres ? (ah oui, il est en dernier ?)
C'est patterns revenaient dans deux publications d'analyse de répertoire reposant sur la détection du CDR3. Etant majoritaires mais pas non plus exactes, j'ai inclut en plus le dernier. Comme tu l'as fait remarquer, il est en dernier; il y a un break qui arrête la recherche au premier pattern trouvé. Il est donc pris en compte que dans le cas ou les deux premier échouent.
***
Branche cdr3-c++.
Le coeur est 0aae0cf : la JUNCTION est ce qui va de la Cys104 à la Phe118/Trp118 :
- Repris les séquences gappées V
- Autant faire aussi des séquences gappées J, alignées sur les motifs dont parle Florian. IMGT ne les propose pas, on le fait donc (c2b0dfc)
On utilise l'alignement déjà fait dans align_against_collection. Pour l'instant, c'est simple : si on a 3 délétions à la fin du V, on considère que la position de référence de la Cys104 est 3 nucléotides plus à droite. Bref, on ne prend pas en compte d'autres indels qui pourraient arriver. Ce calcul pourrait être amélioré en récupérant la position exacte de l'alignement.
Il y a donc des cas où cela marche et des cas non (mais ou on devrait avoir la bonne longueur à +/- 1, voire 2, mais donc mauvaise prédiction de prédictif), voir les derniers commits de tests. Pour la release 2016.03 (qui doit avoir lieu cette semaine), on fera encore quelques adaptations, mais cette détection sera toujours marquée comme "expérimentale".
Florian, pourrais-tu regarder ce que cela donne ? Cela serait particulièrement utile que tu lance sur tes données ou sur les données de test en comparant ton script et en regardant les cas où il y a des différences. Attention, il faut faire "make get-all-data" dans germline pour récupérer/créer les fichiers gappés.
***
Branche cdr3-c++ mise à jour → c’est bon, on identifie maintenant la position de Cys104 et Phe118/Trp118 précisément dans la matrice de programmation dynamique (505c29d). Normalement on devrait maintenant trouver la bonne chose dans quasiment tous les cas.
(Dernier détail : IMGT va mettre certaines séquences comme "non-productives" car il y a des stop à l'extérieur du CDR3. Le "p" ou "u" calculé par Vidjil se limite à l'intérieur du CDR3.)
***
Je reviens après avoir fait un petit tour dans les résultats.
Premier point : ça marche super bien !
J'ai toutefois deux ou trois points.
- Les autres plate-formes incluent dans leur CDR3 les codons de la cys et de la phe/trp. Je pense que pour coller au mieux niveau interopérabilité, il faudrait aussi les inclure.
- Sinon, je pense qu'il y a en effet un problème au niveau de la position start. Le bug vient de savoir si la position de début est inclusive ou exclusive, mais cela provoque par exemple un mauvais positionnement du CDR3 dans l'interface web du CDR3.
- Le dernier point, c'est de savoir si vidjil doit chercher ou non les codons stop aussi en amont/aval. Certes, le CDR3 est fonctionnel, mais la séquence ne le sera peut-être pas. Soit il faut une double feature stop-cdr3 et stop-sequence, soit une seule qui prenne en compte les deux possibilités. Toutes les séquences que j'ai trouvées non conformes le sont à cause de ce point. En amont, ce serait relativement simple; en aval, je ne sais pas quelle est la limite avant qu'un codon stop soit handicapant lors de la traduction.
***
merci Florian pour tes remarques et ton travail là-dessus ! Je vais pousser bientôt tout cela dans dev.
1) Oui. Tu as raison, d'un côté, on doit donner ce que tout le monde attend... mais, de l'autre, on doit respecter les définitions IMGT. On va donc mettre les *deux* infos dans le json, cdr3 et junction, et chacun choisit ce qu'il veut.
2) A priori toutes les positions sont inclusives, normalement le c++ respecte cela. Après, on peut changer le côté browser pour qu'il respecte mieux, je vais enquêter
3) Disons que, pour l'instant, on ne dit que si le CDR3 est productif, pas plus. Le problème pour s'étendre "plus loin" est tout le problème du calcul de la séquence représentative. On peut avoir des reads d'un clone qui sont productifs, d'autre non. Bref, on mettra une tâche pour cela, mais on verra ultérieurement, à une prochaine release. Merci de garder tes séquences discordantes quelque part, on en aura bientôt besoin.
***
merci encore Florian ! C'est mergé.
***
#1370, #1371, #1372
***
@mikael-s @Duez @flothoni @magiraudhttps://gitlab.inria.fr/vidjil/vidjil/-/issues/1544Exploiter les qualités des .fastq ?2019-09-16T16:58:44+02:00Vidjil TeamExploiter les qualités des .fastq ?Difficile, pas de standard... et pour faire quoi ? Si c'est juste pour implémenter un filtre, il doit y avoir cela en sortie des séquenceurs.
Après, cela pourrait être mieux (calcul e-valeur en fonction, k-mots en fonction ?), mais bof...Difficile, pas de standard... et pour faire quoi ? Si c'est juste pour implémenter un filtre, il doit y avoir cela en sortie des séquenceurs.
Après, cela pourrait être mieux (calcul e-valeur en fonction, k-mots en fonction ?), mais bof.
***
Disons que ce qu'on a vu sur les problèmes de représentative (https://www.producteev.com/workspace/t/553e1de8b1fa09d063000007) montrent plutôt qu'on s'en sort déjà bien sans regarder la qualité.
***
@nobodyhttps://gitlab.inria.fr/vidjil/vidjil/-/issues/3196.vidjil: better document `top` and/or make it optionnal2019-07-23T10:03:08+02:00Mathieu Giraud.vidjil: better document `top` and/or make it optionnalIn https://github.com/ablab/y-tools/commit/41687407b738436b2c05615afa24548f83fbc595#diff-dfa29d568694d4d8189ce3e61b44972dR79
@eodus assigns a `"top": 1` for every clone. We are doing almost the same in `vidjil-algo` (`json_clone["top"] =...In https://github.com/ablab/y-tools/commit/41687407b738436b2c05615afa24548f83fbc595#diff-dfa29d568694d4d8189ce3e61b44972dR79
@eodus assigns a `"top": 1` for every clone. We are doing almost the same in `vidjil-algo` (`json_clone["top"] = 0`).
It looks like that the actual `top` value used in the ~client is then computed by fuse.py. We should investigate and better document the value.https://gitlab.inria.fr/vidjil/vidjil/-/issues/5Interacting with RepSeq software2019-04-03T07:49:46+02:00Mathieu GiraudInteracting with RepSeq softwareWe develop the web application (both client and server) to be independent from the Vidjil algorithm. We try to include or to link several software to pre-process, process, or post-process RepSeq data. We both use and propose APIs to work...We develop the web application (both client and server) to be independent from the Vidjil algorithm. We try to include or to link several software to pre-process, process, or post-process RepSeq data. We both use and propose APIs to work within a ecosystem of RepSeq software. We contribute to open formats to exchange RepSeq data.https://gitlab.inria.fr/vidjil/vidjil/-/issues/3852Grep reads et vidjil-algo : le fichier résultant peut mélanger FASTA et FASTQ2019-03-21T09:04:50+01:00Mikaël SalsonGrep reads et vidjil-algo : le fichier résultant peut mélanger FASTA et FASTQIl s'agit du fichier produit pour chaque clone de Vidjil-algo. Il contient également la séquence de la fenêtre et la séquence consensus. Ces deux séquence sont ajoutées au format fasta alors qu'il y a des chances que le fichier de reads ...Il s'agit du fichier produit pour chaque clone de Vidjil-algo. Il contient également la séquence de la fenêtre et la séquence consensus. Ces deux séquence sont ajoutées au format fasta alors qu'il y a des chances que le fichier de reads soit au format FASTQ (et donc dans ce cas les reads seront sortis en FASTQ).
Ce mélange de format empêche toute analyse par un autre logiciel sans manipulation manuelle.https://gitlab.inria.fr/vidjil/vidjil/-/issues/3645Extend normalization with custom normalized_reads2018-12-28T08:13:10+01:00Mathieu GiraudExtend normalization with custom normalized_readsAter #3644, implement `normalized_reads` handling in `normalize()`Ater #3644, implement `normalized_reads` handling in `normalize()`Thonier FlorianThonier Florianhttps://gitlab.inria.fr/vidjil/vidjil/-/issues/3585Labels should be stored in the fused file2018-12-04T18:41:45+01:00Mikaël SalsonLabels should be stored in the fused fileDiscussed with @meidanis: the labels that are stored in the .vidjil file appear to be discarded by the `fuse.py` file. This is a pity!Discussed with @meidanis: the labels that are stored in the .vidjil file appear to be discarded by the `fuse.py` file. This is a pity!Mathieu GiraudMathieu Giraudhttps://gitlab.inria.fr/vidjil/vidjil/-/issues/3457Utilisation du format AIRR2018-11-20T09:41:01+01:00Mathieu GiraudUtilisation du format AIRRAIRR nous demande explicitement (le 17 juillet pour le 24...) si on est prêt à utiliser leur format, éventuellement amendé.
- vidjil-algo: en sortie vidjil#2828. Je pense qu'on peut s'engager raisonnablement à faire une première version...AIRR nous demande explicitement (le 17 juillet pour le 24...) si on est prêt à utiliser leur format, éventuellement amendé.
- vidjil-algo: en sortie vidjil#2828. Je pense qu'on peut s'engager raisonnablement à faire une première version pour 2018.09.
- client: conversion/entrée via fuse.py, TBD ? Cela me semble plus délicat de s'engager.
Peut-on en discuter de vive voix à 15h ?Algo 2018.09Mathieu GiraudMathieu Giraudhttps://gitlab.inria.fr/vidjil/vidjil/-/issues/3566Supprimer / rationaliser le format .vdj des headers ?2018-10-24T16:27:47+02:00Mathieu GiraudSupprimer / rationaliser le format .vdj des headers ?On l'a peut-être oublié, nous disons sur stdout et dans la ~doc que le `.vdj.fa` est (l'un des) "main output file"(s).
Voir aussi http://www.vidjil.org/doc/vidjil-algo/#main-output-files
```
>clone-001--IGH--0000008--0.0608%--lcl|FLN1FA...On l'a peut-être oublié, nous disons sur stdout et dans la ~doc que le `.vdj.fa` est (l'un des) "main output file"(s).
Voir aussi http://www.vidjil.org/doc/vidjil-algo/#main-output-files
```
>clone-001--IGH--0000008--0.0608%--lcl|FLN1FA001CPAUQ.1|-[106,232]-#2 - 127 bp (54% of 232.0 bp) + VDJ 1 54 73 84 85 127 IGHV3-23*05 6/ACCCGGGAGGAACAATAT/9 IGHD6-13*01 0//5 IGHJ4*02 IGH SEG_+ 1.952469e-18 1.644625e-18/3.078448e-19 {52(45)96 p CTREEQYSSWYFDFW}
CTGTACCTGCAAATGAACAGCCTG ...
```
Une fois que l'on a #2828, on peut se demander ce qu'on doit conserver.
Est-ce que ces headers sont utiles ? Oui pour ~"dev\-tests\-curated\-vdj", mais qui pourrait utiliser autre chose #3567.
On garde bien sûr la sortie `.vdj.fa`... mais :
- cas extrême : on vire ce header, ou tout ce qui est après l'espace
- ou, après la partie sans espace, on met directement le ` .tsv` AIRR #2828 (problème: trop long)
- ou au moins le *début* du .tsv, à supposer qu'on ait un ordre intelligent - (!xxx essaie de faire cela)
Dans tout les cas, au minimum, mettre la génération de tout cela dans une sous-classe de `CloneOutput` #3592.https://gitlab.inria.fr/vidjil/vidjil/-/issues/3590AIRR et nombre de reads : finalement duplicate_count ?2018-10-24T16:16:48+02:00Mathieu GiraudAIRR et nombre de reads : finalement duplicate_count ?J'allais envoyer le mail à AIRR quand je suis retonbé sur cette discussion par mail:
> > (Vidjil) Note that we focus on *clones* throughout all the Vidjil platform, not on individual reads. We plan to use the "consensus_count" key of th...J'allais envoyer le mail à AIRR quand je suis retonbé sur cette discussion par mail:
> > (Vidjil) Note that we focus on *clones* throughout all the Vidjil platform, not on individual reads. We plan to use the "consensus_count" key of the AIRR format to encode the number of reads belonging to a clone, is it the good way to go ?
> (JVH, AIRR) For counting clones, the `duplicate_count` field would be more appropriate; `consensus_count` is for UMI consensus read annotation. However, if you want a clonotype summary report (eg, count of unique CDR3s without V/J annotations), then the Rearrangement format isn't really suitable for that. This might be a format we have to consider designing, if there is enough demand for it. (This is a grey area though, because it's more of a custom analysis output than something we can standardize.)
Voir https://gitlab.inria.fr/vidjil/vidjil/issues/3457#note_125973 par @flothoni et autres commentaireshttps://gitlab.inria.fr/vidjil/vidjil/-/issues/2828Export csv AIRR depuis l'algo2018-10-24T16:16:47+02:00Mathieu GiraudExport csv AIRR depuis l'algoDai N. aurait été intéressé par une sortie csv de l'algo, "comme depuis le client".
Peut-être le .vidjil peut aussi lui convenir.Dai N. aurait été intéressé par une sortie csv de l'algo, "comme depuis le client".
Peut-être le .vidjil peut aussi lui convenir.Algo 2018.092018-10-27https://gitlab.inria.fr/vidjil/vidjil/-/issues/2329app/analyze : conserver lien entre séquence et dénomination2018-10-18T14:36:34+02:00Thonier Florianapp/analyze : conserver lien entre séquence et dénominationRemarque de Véronique :
> peux-t-on retrouver à partir d'une séquence retournée par l'app analysis la séquence d'origine ?
L'idée est de savoir si l'on met trois séquences sen même temps laquelle est laquelle dans le segmenteur.Remarque de Véronique :
> peux-t-on retrouver à partir d'une séquence retournée par l'app analysis la séquence d'origine ?
L'idée est de savoir si l'on met trois séquences sen même temps laquelle est laquelle dans le segmenteur.https://gitlab.inria.fr/vidjil/vidjil/-/issues/3563Use a fasta file for -l ?2018-10-16T18:39:26+02:00Mathieu GiraudUse a fasta file for -l ?Do we have a reason to have a specific format for `-l` ?Do we have a reason to have a specific format for `-l` ?https://gitlab.inria.fr/vidjil/vidjil/-/issues/3451Format pour transmettre les barplots widgets2018-10-08T11:02:00+02:00Mathieu GiraudFormat pour transmettre les barplots widgetsVoir #3407
Voir aussi https://gitlab.inria.fr/vidjil/stats/issues/199#note_34038
(ci une simple liste [.85, .4, .23, .65] pourrait suffire.
cc @RyanHerbVoir #3407
Voir aussi https://gitlab.inria.fr/vidjil/stats/issues/199#note_34038
(ci une simple liste [.85, .4, .23, .65] pourrait suffire.
cc @RyanHerbhttps://gitlab.inria.fr/vidjil/vidjil/-/issues/3362À quoi sert le ref dans les fichiers .g / à quoi sert germline_id2018-09-07T09:43:25+02:00Mikaël SalsonÀ quoi sert le ref dans les fichiers .g / à quoi sert germline_idLors d'une mise à jour du germline il est nécessaire de mettre à jour les fichiers `.g` afin de faire passer le test `should-get-tests/11-get-saved-germline-id.should-get`.
Le champ `"ref"` des fichiers germlines renseigne une version p...Lors d'une mise à jour du germline il est nécessaire de mettre à jour les fichiers `.g` afin de faire passer le test `should-get-tests/11-get-saved-germline-id.should-get`.
Le champ `"ref"` des fichiers germlines renseigne une version précise des germlines. Pourquoi ? À quoi cela sert ? Je comprends qu'il soit nécessaire d'avoir une version minimale mais je ne vois pas l'utilité d'imposer une version (et de devoir la changer à chaque mise à jour des germlines).