Résumé de la politique du Programme mondial sur la génétique de la maladie de Parkinson (GP2) en matière de normalisation du code

Dans l’ensemble, le Programme mondial sur la génétique de la maladie de Parkinson (GP2) vise une politique du « sans surprises », où analyses, projets et manuscrits sont coordonnés et communiqués de manière ouverte et transparente. Le GP2 souhaite que les données et le code soient utilisés aussi largement et ouvertement que possible, aussi est-il nécessaire de disposer d’un code normalisé pour toutes les équipes d’analyses. A l’intention de tous les membres du GP2 et des entités extérieures au GP2 qui envisageraient de mener des analyses sur les données du GP2, il est rappelé l’importance de disposer d’un code propre, organisé, reproductible, ouvert et disponible à l’ensemble de la communauté scientifique. Le code doit appliquer les lignes directrices en matière de normalisation ; le GP2 doit être mentionné et le code doit être mis à la disposition de la communauté scientifique via GitHub.

Introduction

Le Programme mondial sur la génétique de la maladie de Parkinson (GP2) est un effort international dont l’objectif est d’opérer un saut qualitatif dans les connaissances portant sur la base génétique de la maladie de Parkinson (MP) et de démocratiser l’accès aux résultats et aux données. Le GP2 est financé par Aligning Science Across Parkinson’s initiative (ASAP) et parmi les objectifs stratégiques de ce programme figurent le soutien apporté à la collaboration, à la génération de sources d’information et à la démocratisation des données. La diffusion du code et des données du GP2 est l’un des objectifs majeurs du GP2 et l’ASAP encourage la publication généralisée, rapide et ouverte des résultats.

Aperçu général

L’objectif de cette politique est d’assurer que :

Le code et les flux du GP2, issus des analyses menées par le consortium GP2, sont diffusées dans leur intégralité, rapidement et avec rigueur.
Les codes et flux issus des analyses dirigées par le consortium GP2 sont normalisés, organisés et mis à la disposition du public sur GitHub.

Les lignes d’orientation de la normalisation du code viennent compléter la politique de publication du GP2. Veuillez vous référer à ce document pour les questions de gestion du consortium GP2 en cas de situations inusitées.

La politique de normalisation du code met en exergue les meilleures pratiques de normalisation du code adoptées par le comité directeur du GP2 et les analyses dirigées par le consortium GP2 en complément des publications dirigées par le consortium GP2. Les chercheurs extérieurs qui utilisent les données du GP2 sont fortement encouragés à intégrer ces pratiques ainsi qu’à produire des analyses de grande qualité et de science ouverte. En raison de la tendance croissante du milieu à utiliser les blocs-notes Python et Jupyter plutôt que R, ce document porte sur Python. Nous sommes conscients que de nombreux chercheurs du GP2 utiliseront peut-être R ou d’autres outils, tout en continuant à promouvoir un code organisé, ouvert et reproductible au sein de la communauté du GP2.

Pour vous motiver, n’oubliez pas que si le nettoyage du code est fastidieux, il permet au GP2 de créer son code et vous êtes encouragés à suivre également ces normes. Si le code n’est pas clair et propre et ne communique pas de lui même, produit-il réellement l’impact que vous souhaitez ? Un code propre signifie également que vous consacrerez moins de temps, en aval, à expliquer à maintes reprises les analyses et les concepts. C’est donc une situation « gagnant-gagnant ». Un code propre permet la réplication et la transparence. Le GP2 est engagé à l’égard de la science ouverte et de la collaboration par le biais de la transparence du code et de l’inclusivité.

Ci-dessous, nous décrivons quelques informations et flux de travail sur Python comme langage primaire, Anaconda comme mode de distribution préférentiel de Python, PEP8 comme structure de langage, Google Cloud comme environnement de stockage et Terra comme environnement d’analyse en nuage. Nous soulignons également l’importance de disposer d’un document clair qui indique le flux de travail et le raisonnement, pour chacune des analyses, appelé README. Telles sont les normes de bases qui seront suivies par le GP2 et, nous l’espérons, par l’ensemble de la communauté scientifique.

Avant de commencer, voici quelques éléments de codage basiques sous Python

Tout ce qui concerne le calcul informatique pour le GP2 sera vraisemblablement fait surTerra, AnVIL du NHGRI ou toute infrastructure similaire basée sur le nuage.
- Une assistance analytique et financière sera disponible pour les projets et groupes qui rencontreraient des contraintes logistiques et financières.
Python3+ sera le langage principal pour les analyses du GP2 ; il y aura un support limité pour R et d’autres langages. Cela permet d’exploiter les bases actuelles du code du LNG Data Science Group du National Institute on Aging.
Pour apprendre à utiliser Terra, commencez par ouvrir un compte AMP-PD, ce qui est un excellent point de départ.
- Cette solution propose d’excellents blocs-notes « pour démarrer » (où vous pouvez écrire et exécuter votre code) ainsi que des espaces de travail et d’innombrables données que vous pouvez utiliser.
- Les documents de démarrage disponibles sur Terra.bio sont également excellents.
Devenir un expert en Python en deux semaines…
- Exécutez cela une fois par jour.
- Exécutez celaune fois par semaine (grâce à nos bons amis du NSA via FOIA).
- Google Colabs est également un endroit peu coûteux et peu stressant pour apprendre la structure des blocs-notes et se familiariser avec Python ( Afficher les blocs-notes dans Drive )
Un bon code est un code simple, clair et normalisé qui obéit à sa propre grammaire, semblable à une recette.
- Les Guides de Style Google sont un excellent point de départ.
- PEP8 est la « grammaire » préférentielle pour Python.
- Visual Studio Code est notre éditeur préféré au sein du GP2 car il comporte des extensions qui permettent de normaliser le style du code, mais utilisez ce qui vous convient le mieux.
Le principal langage des équipes de support est Python3. Si vous utilisez les mêmes outils que nous, cela nous permettra de partager avec vous des outils et de vous assister dans vos projets plus efficacement.
- Tous les systèmes internes utilisés pour les outils et les codes sont rédigés en Python3.
- Le partage des sources du GP2 se fera en Python3 dans la grande majorité des projets.

Comment télécharger Anaconda/Python pour une utilisation locale

Il convient de souligner que lorsque nous programmons avec Python localement, nous utilisons la distribution Anaconda pour assurer un environnement entièrement équipé en Python3. LNG a produit un document qui explique comment démarrer avec Anaconda, que vous trouverez ici.

Principaux points et aperçu général

Vous devez vous doter d’une méthode de contrôle de la version pour éviter les accidents. Faites-en votre bloc-notes de labo électronique. Le labo du projet GP2 dispose de son propre GitHub en prévision des futurs flux. Comme tout ce qui concerne le GP2, tout ce qui est exposé ici est une information publique.
- Si ce n’est pas tout à fait au point pour le public, ne vous inquiétez pas ! Créez votre référentiel privé et quand le code sera terminé, vous pourrez le rendre public.
- GitHub permet de rendre le contrôle de la version et la collaboration très simples, en particulier grâce à leur nouvelle interface bureau ; documents complémentaires sur le démarrage disponibles ici.
La création d’un document README est essentielle. Nos documents README sont non seulement une façon de communiquer avec autrui mais, ce sont également des documents vivants en constante évolution, bien qu’ils comprennent toujours des renseignements tels que :
- Auteurs, collaborateurs, nom du projet, objectif du projet, flux de travail proposé pour les analyses, date de démarrage, date de la dernière mise à jour, chemins d’accès aux répertoires de travail, chemins d’accès aux fichiers.
- Parmi les bons éditeurs Markdown gratuits permettant de créer un document README, il y a le fabuleux stackedit.io.
L’équipe des analyses du GP2 travaille sur des codes expérimentaux de démonstration du concept en utilisant Google Colabs pour profiter des GPU gratuits, partager facilement et introduire aisément des modifications sur l’environnement local Jupyter, le cas échéant.
En guise de principe général, dès lors qu’un groupe qui collabore sur un même projet comporte plus de 2 ou 3 personnes, une version de contrôle est nécessaire.
Avant de partager un projet ou manuscrit avec le réseau du GP2, il est obligatoire de disposer d’un contrôle de la version et d’une source de codage transparente et intelligible.
- Ce code fera l’objet d’une vérification avant que la publication ne soit autorisée si les moyens du GP2 sont engagés, sous forme d’assistance analytique ou financière.

Organiser le code

L’une des manières d’organiser le code, est expliquée ici
- Cette source explore la création de fonctions, modules et autres façons pratiques de compartimenter votre travail.
- Votre code ne doit pas obligatoirement suivre ces préceptes si vous n’êtes pas à l’aise, mais il est cependant nécessaire qu’il respecte un ordre intuitif.
- Considérez que votre code fait partie intégrante de votre manuscrit. Si un réviseur ne comprend pas votre manuscrit, comment ce dernier pourra-t-il être recevable pour les normes de science ouverte du GP2 ? Il en va de même pour le code.
- Bien que le GP2 n’impose pas un format de code particulier, veuillez néanmoins vous efforcer d’être le plus clair possible.

Normalisation des codes dans Python

Nous suivons de très près les préceptes de la Proposition d’enrichissement personnel Python (PEP8) de la Programmation Python. Le document PEP8 explique comment rédiger correctement un code Python et a pour objectif d’améliorer la lisibilité et la cohérence du code Python.
- Une source complète mais assimilable peut être trouvée ici.
- La plupart des environnements de développement intégré (EDI) disposent d’un plug-in pour les aider à respecter ces normes.
  - Un exemple est celui du code Visual Studio autopep8 plugin.
Dans les blocs-notes, nous utilisons un modèle de canevas pour nous rappeler et rappeler aux utilisateurs les motifs qui sous-tendent les projets. En utilisant les blocs-notes, Markdown se comporte en ami pour aider l’utilisateur à s’y retrouver, tout en assurant le suivi de ce qui a été exécuté.
- Voici le modèle actuel de canevas .
  - Il peut être adapté à vos besoins.
  - Le cadre général doit être appliqué pour tout code lié aux projets bénéficiant d’une assistance directe du GP2. Cela permet de faciliter le suivi et les opérations de dépannage.

Meilleures pratiques de la plateforme en nuage

Dans le cadre de l’AMP-PD et vraisemblablement du GP2, nous utiliserons la plateformeTerra pour les flux de rédaction, correction et exécution des analyses.
- La plateforme Terra a été conçue par le Broad Institute et le MIT pour exploiter les infrastructures commerciales en nuage (options multiples) et affiche un environnement complet en Python3 interactif dans une structure de bloc-note (un peu comme Jupyter).
  - Si vous n’êtes pas familiarisé avec l’informatique en nuage, Google propose une excellente introduction au jargon ici, qui couvre les bases de ce qu’est un projet, un compartiment, un container ainsi que d’autres concepts clé pour vous permettre d’avancer.
  - Quelques exemples spécifiques de Terra ont été compilés par l’équipe AMP-PD ici.
  - Vous trouverez dans ce petit aide-mémoire des conseils pratiques sur la façon de déplacer des fichiers dans l’infrastructure en nuage.
  - Les meilleures pratiques de Google en matière d’identification, de stockage de donnée et de gestion de données sont disponibles ici.
Il existe deux différences majeures entre l’exécution des données au niveau local et sur le nuage.
- Localement, vous payez pour le stockage (que ce soit sur votre propre ordinateur ou sur le cluster d’une institution), tandis que sur le nuage, le stockage est payé (ex. par AMP-PD ou par le GP2).
- Localement, vous ne payez pas pour exécuter des flux d’analyses (jamais sur votre propre ordinateur, mais le paiement d’un cluster revient à un institut), tandis que sur le nuage, les utilisateurs payent pour chacune des analyses qu’ils exécutent (ex. via leur IP ou institution).
Les équipes des analyses AMP-PD et du GP2 ont rédigé divers types de flux d’analyses (lien) qui peuvent être améliorés.
- Parce que vous payez pour l’environnement que vous créez et la quantité de données auxquelles vous accédez, il est essentiel de concevoir et de planifier vos analyses avec le plus grand soin.
  - Vous pourrez trouver ici un exemple des coûts d’exécution qui pourront vous orienter.
- Il est possible d’actualiser l’environnement en nuage en backend, c’est pourquoi il convient d’enregistrer et de gérer les compartiments auxquels vous accédez pour pouvoir vous y référer ultérieurement.
- Parce que vous payez pour l’environnement que vous mettez en place et la durée d’utilisation, mettez-le en pause ou effacez-le entièrement lorsque vous ne l’utilisez pas, afin de ne payer que ce que vous utilisez.

Un dernier commentaire pour nos amis qui se chargent de la « liquidation ».

La transparence, l’ouverture et la reproductibilité ne s’appliquent pas uniquement à des projets informatiques. Nous recommandons vivement des outils tels que protocols.io ou l’utilisation du bloc-notes Rocket pour la normalisation des tâches et expériences de labo. Le groupe de travail du GP2 sur l’analyse des données complexes de la maladie et celui sur la diffusion du code et des données complexes de la maladie souhaiteraient que certaines pratiques deviennent obligatoires afin de refléter le travail que nous menons sur le front du calcul informatique. Nous encourageons également la normalisation et la transparence des pratiques d’acquisition d’échantillons et d’identification d’échantillons en ligne, bien qu’elles ne s’inscrivent pas directement dans le cadre de notre travail.

Remerciements

Tous les manuscrits, pré-imprimés, résumés et posters issus de l’utilisation des flux d’analyses de données du GP2 doivent comporter la mention ASAP et GP2, dans les termes suivants :

Le code utilisé pour la préparation de ce flux provient du Programme mondial sur la génétique de la maladie de Parkinson (GP2). GP2 est financé par l’initiative Aligning Science Against Parkinson’s (ASAP) et mis en œuvre par la Fondation Michael J. Fox pour la recherche sur la maladie de Parkinson ( MJFF ). Pour une liste complète des membres du GP2, voir ici.

La Fondation Michael J. Fox, l’ASAP et le comité directeur du GP2 se réservent le droit de modifier les conditions de l’accord, procédant pour ce faire à une notification des modifications en question sur cette page. Toute modification prend effet immédiatement après sa publication (sauf indication contraire). Nous vous invitons à consulter cette page régulièrement pour prendre connaissance des conditions de l’accord en vigueur.

« Code de conduite des codeurs »

Veuillez adhérer à cecadre conceptuelpour collaborer dans des projets de codage dans le cadre du GP2.

Télécharger