Fork et pull request : la participation open source par l’exemple
Ci-gît YAML
Notre dossier sur la maîtrise de Git et de ses plateformes :
La participation aux projets open source est en général perçue comme complexe, souvent à cause de l'outil de gestion de versions Git. Mais lorsqu'il s'agit de proposer de petites modifications, tout peut se faire simplement en ligne via des plateformes comme GitHub.
Participer à un projet open source peut se faire de bien des manières : en parlant de l'initiative autour de soi, en aidant à la documentation, à la traduction, au financement, en assistant l'équipe lors d'évènements, etc.
Git : un petit outil qui change la vie (quand on le maîtrise)
S'il n'est pas nécessaire de savoir développer, il faut parfois faire preuve d'un certain formalisme et utiliser des outils spécifiques. Cela permet à l'équipe en charge de mieux prendre en compte les remontées de la communauté, d'en assurer le suivi. Et surtout éviter que tout ne soit perdu dans des milliers de commentaires et emails.
Pour cela, les projets open source ont souvent recours à des plateformes mêlant fonctionnalités pour développeurs et services communautaires. Dans le domaine du logiciel, on pense à des outils comme GitLab ou GitHub, qui ont pour point commun de se reposer sur un même outil créé par Linus Torvalds en 2005 : Git.
Ce gestionnaire de versions distribué a rapidement montré son intérêt au-delà du code, permettant de gérer tout aussi bien l'évolution de documents, seul ou en équipe, et pourquoi pas des textes de loi. Mais c'est un outil en ligne de commandes, qui n'est pas toujours simple à prendre en main par les débutants.
Les applications et plateformes qui l'utilisent proposent donc en général des interfaces graphiques simples pour guider le néophyte dans les méandres des commits, forks et autres pull requests.
- Open source, libre et communs : contribuer ne nécessite pas de développer
- Apprenez à utiliser Git : les bases pour l'évolution d'un document
- Git remote : comment héberger vos documents et codes source sur un serveur
- Git : comment travailler avec plusieurs remotes
- Fork et pull request : la participation open source par l'exemple
- GitHub CLI 1.0 est disponible : comment l'installer et l'utiliser
Une petite participation pour commencer
Pour vous montrer qu'il peut être facile de participer à un projet de la sorte, nous nous sommes lancé un défi : proposer une application à intégrer au nouveau gestionnaire de paquets de Microsoft, winget. Ce dernier repose sur une base communautaire maintenue via GitHub. Un guide explique comment participer.
Avant de démarrer, il y a quelques petites choses à savoir et à faire. Tout d'abord, il faudra vous créer un compte GitHub si vous n'en avez pas. Le service est gratuit, notamment pour l'hébergement de projets open source.
Pendant la procédure, Microsoft vous demandera d'accepter son Contributor License Agreement (CLA) pour s'assurer que la contribution est faite à titre personnel, ou avec l'accord de votre employeur. Qu'il s'agît bien d'une contribution originale (pas de reprise d'un tiers sans son accord), qu'elle peut être analysée/utilisée, etc.
L'entreprise dispose d'ailleurs d'un code de conduite open source accompagné d'une FAQ. Des précautions qui peuvent paraître excessives, mais qui sont de plus en plus courantes dans de gros projets open source pour éviter tout problème, encadrer les pratiques des contributeurs et les échanges avec la communauté.
Création d'un manifeste
Sur GitHub, winget se découpe en deux projets. Tout d'abord winget-cli, l'application elle-même, diffusée sous licence MIT. Puis winget-pkgs, qui contient la liste des applications qu'il est possible d'installer. Elle prend la forme de manifestes, des fichiers texte basés sur le format YAML pensé pour être facilement lisible.
Les règles à respecter sont détaillées ici. L'exemple est le suivant :
Id: string # publisher.package format
Publisher: string # the name of the publisher
Name: string # the name of the application
Version: string # version numbering format
License: string # the open source license or copyright
InstallerType: string # enumeration of supported installer types (exe, msi, msix, inno, wix, nullsoft, appx)
Installers:
- Arch: string # enumeration of supported architectures
Url: string # path to download installation file of the specified version
Sha256: string # SHA256 calculated from installer
On le voit, il s'agit de simples variables suivies d'une valeur, avec une indentation (sous la forme d'espaces uniquement) lorsque c'est nécessaire, permettant par exemple de déclarer différents fichiers d'installation. Microsoft propose même un outil prêt à l'emploi ainsi qu'un script PowerShell pour vous simplifier la vie.
Ils sont organisés dans le répertoire de la manière suivante :
manifests/nom_de_l_éditeur/nom_de_l_application/numéro_de_version.yaml
Avant de soumettre un manifeste, il faut respecter quelques règles. La première est bien entendu d'éviter les doublons : si une contribution a déjà été faite ou est en cours, n'en ajoutez pas. Ensuite, il faut créer votre manifeste, puis le tester. C'est seulement après que vous pourrez l'envoyer.
Création et test du manifeste
Dans notre cas, nous avons décidé de proposer le gestionnaire de clés de sécurité Yubikey de Yubico. Après vérification, il n'était pas disponible ou en traitement. La première étape est de déterminer comment l'installer de manière « silencieuse », sans que l'utilisateur n'ait à interagir. Le plus souvent, cela passe par l'ajout de l'argument /S ou /silent. Parfois, lancer l'exécutable avec /? permet d'avoir la liste des possibilités. Ce n'était pas le cas ici.
Nous avons donc téléchargé l'outil, l'avons lancé avec /S, avec succès. Étape suivante : remplir le manifeste. Nous ne l'avons pas fait via les outils automatiques de Microsoft, un simple éditeur de texte suffit. Veillez à y écrire en anglais, winget étant prévu pour une utilisation internationale, sans traduction locale pour le moment.
Voici le résultat obtenu pour la version actuelle (1.1.5) :
Id: Yubico.YubikeyManager
Version: 1.1.5
Name: Yubikey Manager
AppMoniker: yubimgr
Tags: 2fa, security, auth
Description: Official tool to configure FIDO2, OTP and PIV functionality on your YubiKey
Homepage: https://www.yubico.com/products/services-software/download/yubikey-manager/
Publisher: Yubico
License: Copyright (c) Yubico 2020. All Rights Reserved.
Installers:
- Arch: x64
Url: https://developers.yubico.com/yubikey-manager-qt/Releases/yubikey-manager-qt-1.1.5-win64.exe
Sha256: 719F266675616F21070EA11FE0B1C75AF02C54494288E7E0164B4280BE90CE33
InstallerType: exe
Switches:
Silent: /S
SilentWithProgress: /S
La plupart des éléments peuvent être récupérés sur le site de l'éditeur. Pensez à tous les préciser. Les tags doivent aider à la découverte de l'application lors d'une recherche. L'empreinte SHA-256 se calcule facilement avec la commande Get-FileHash sous PowerShell (voir ci-dessous). Vous pouvez également passer par la commande winget hash. Nous avons utilisé notre propre outil CheckHash.
Une fois le fichier créé, il faut le valider et le tester avec les commandes suivantes :
winget validate nom_du_manifeste.yaml
winget install -m nom_du_manifeste.yaml
La seconde indique à winget de tenter une installation depuis votre manifeste plutôt que sa base de données. Si vous obtenez le message « installé correctement », vous pouvez le soumettre à l'équipe via GitHub. Sinon, pensez à vérifier que vous n'avez pas des espaces mal formés avec un outil de validation YAML.
Participation via Git, un peu de théorie
Avant de passer à la suite, voici quelques notions et termes à connaître concernant Git. Ce que nous allons réaliser se nomme pull request (PR ou requête de tirage). Une procédure détaillée dans le manuel officiel qui consiste à créer une version modifiée du code original puis de proposer (request) à son auteur de la reprendre (pull).
Chaque code source est contenu dans un dépôt (repository). Chaque modification apportée est nommée commit. Plusieurs branches peuvent co-exister, mais il y a au minimum une branche principale (master). On peut en créer autant qu'on le souhaite, permettant de travailler sur plusieurs modifications à la fois.
Pour une application donnant l'heure, on pourrait créer une branche « ajouter-date » dans laquelle on modifierait le code pour fournir la date. Une autre « ajouter-meteo » ou « changer-fuseau-horaire ». Toute la « magie » de Git, c'est que plusieurs développeurs peuvent travailler en parallèle sur leur propre branche (parfois à plusieurs).
Lorsque le travail est terminé, il suffit de fusionner les branches (merge). La procédure de pull request est ce qui permet à un contributeur extérieur de proposer des modifications. Chacun peut donc apporter sa pierre à l'édifice.
Cela se fait en trois étapes :
- On créé une copie du code originel (un fork)
- On créé une branche pour y effectuer les modifications sans risque
- On génère et on envoie la PR depuis cette branche
Heureusement, pour de petites participations, GitHub facilite la procédure.
Fork, pull request et soumission de manifeste
Vous n'avez même pas à télécharger ou installer Git. Tout peut se faire en ligne. La première étape est donc de créer un fork du dépôt originel. Il s'agit de récupérer tous les fichiers dans un dépôt lié à votre compte. Vous pourrez ainsi le modifier à votre guise puis effectuer vos modifications.
Vous pouvez même faire tout en une seule étape. Rendez-vous sur la page du projet winget-pkgs en étant connecté à votre compte GitHub. Cliquez sur Add file > Create new file (voir ci-dessus). Le fork a été créé dans votre compte, un fichier vide est ouvert. Il faut le nommer. Dans notre cas :
manifests/Yubico/YubikeyManager/1.1.5.yaml
Entrez ensuite le contenu du manifeste tel que vous l'avez testé et validé. Il faudra donner un nom à cette modification (commit), compréhensible par les équipes de winget. Nous optons pour « Add YubikeyManager 1.1.5 ». Cliquez sur Propose new file pour la valider, elle sera alors créée dans la branche « patch-1 » de votre fork.
Vous serez alors invité à la transformer en PR. Dans cette dernière, un texte a été créé automatiquement avec quatre cases à cocher (d'un « x ») pour confirmer que vous avez bien accepté l'accord de contribution CLA, vérifié que l'application n'était pas déjà proposée, que vous avez validé et testé le manifeste.
Vérifiez une dernière fois tous les éléments, que toutes les cases sont cochées, vous pouvez ensuite la valider en cliquant sur Create pull request. Les robots de Microsoft analyseront la PR pour vérifier qu'elle est conforme et fonctionnelle, et que votre accord CLA a bien été donné. En cas de problème, un message sera affiché.
Il vous faudra alors répondre dans les commentaires, l'équipe venant de temps en temps régler les cas en attente. Cela peut néanmoins prendre quelques jours. Si tout va bien, votre proposition sera acceptée puis intégrée. Il sera alors possible d'installer l'application correspondant au manifeste que vous avez créé depuis winget.
Pensez à le mettre à jour quand de nouvelles versions seront disponibles. Si ce n'est pas le cas, un autre pourra le faire à votre place. L'aspect collaboratif de l'open source, c'est aussi ça.
Commentaires (67)
Vous devez être abonné pour pouvoir commenter.
Déjà abonné ? Se connecter
Abonnez-vousLe 21/08/2020 à 06h48
Bon article
Il manquerait pourquoi pas une partie « terminal » avec quelques commandes git, on ne peut pas toujours faire ses PR uniquement via l’éditeur Web
Le 21/08/2020 à 06h51
C’était un peu trash pour le premier tuto, mais il y en aura d’autres
Le 21/08/2020 à 07h05
Deux petits ajouts:
Le 21/08/2020 à 07h11
J’ai opté pour une solution sans le client GitHub Desktop pour simplifier la procédure (j’avais commencé avec, mais pour ce projet c’était ajouter 4⁄5 paragraphes de textes et pas mal de notions pour pas grand chose). Comme dit plus haut, c’est de toutes façons le début d’une série d’articles sur le sujet
Pour le second point, git reset FTW
Le 21/08/2020 à 07h58
Super article, j’ai tellement de mal à trouver de vrai tuto sur la bonne démarche à suivre sur git
J’attends le reste avec impatience.
Le 21/08/2020 à 08h23
Ce site interactif est très bien fait, et ça va des concepts de base à des notions un peu plus avancées:
https://learngitbranching.js.org
Le 21/08/2020 à 07h26
C’est pour moi qui n’arrive pas à comprendre les PR, je vais lire tout ça !
Le 21/08/2020 à 08h04
Il y a aussi l’application gitKraken si on n’aime pas trop utiliser la ligne de commande
Le 21/08/2020 à 08h08
Oui ou l’intégration aux IDE qui est en général assez complète
Le 25/08/2020 à 07h50
Il n’est plus utilisable qu’avec GitHub sur de projet public. J’ai un gitlab perso et tous mes projets open source sont considérés comme privés. Donc j’ai viré GitKraken.
Le 21/08/2020 à 08h31
J’attends avec impatience l’article sur les Flows où la communauté va se déchirer entre Git Flow, Github Flow, One Flow, etc.
Et aussi sur “est-ce que l’on squash” ?
Le 21/08/2020 à 08h45
SourceTree (sur windows; gratuit) et voila on oublie les lignes de commande.
Le 21/08/2020 à 09h21
Quoi que tu fasses avec Git, tu es toujours obligé d’en revenir un jour ou l’autre à la ligne de commandes
Le 21/08/2020 à 09h15
Super article !
Et la série à venir promet d’être intéressante, de quoi améliorer mes compétences sur git !
Le 21/08/2020 à 09h37
tig, et voilà, on oublie ces outils graphiques
Le 21/08/2020 à 10h28
A ne pas confondre avec le tig
Le 21/08/2020 à 10h43
TortoiseGit pour ma part.
Le 21/08/2020 à 11h00
Svn pour les débutants comme moi pour ma part 😅
Le 21/08/2020 à 11h07
Petite précision qui peut paraître anodine : l’indentation doit obligatoirement utiliser quatre espaces. Beaucoup d’éditeurs utilisent, à juste titre, des tabulations pour l’indentation. Donc je pense que c’est important de le mentionner pour les débutants ^^
Alors qu’un seul caractère aurait suffit pour indenter, ceux qui ont créé ce langage ont imposé pour je ne sais quelle raison cette absurdité d’utiliser des espaces pour indenter… Si quelqu’un a des infos pour m’expliquer un tel choix, je suis preneur :-)
Le 21/08/2020 à 12h15
Utiliser des tabulations est considéré comme une mauvaise pratique car il peut avoir une longueur différentes en fonction du logiciel utilisé ou des paramètres défini par l’utilisateur (en fonction ou non de ses préférences). Le “visuel” du code peut donc être différent d’une personne à l’autre ou d’un logiciel à l’autre, le texte peut-être retourné à la ligne si trop longue, etc. Tout ça peut modifier la visibilité/qualité de lecture du code et être source d’erreur. Un éditeur de code utilise une police à chasse fixe (si il est bien configuré) afin que tous les caractères fassent la même largeur pour s’assurer de la lisibilité du code. Utiliser des espaces pour indenter permet de garantir que le code s’affiche exactement pareil chez tout le monde.
Après pourquoi 4 espaces et pas deux ou un, j’imagine que c’est pour que l’indentation soit assez grande pour être tout de suite identifiable. Et pas un seul espace qui est déjà utilisé pour séparer les opérateurs et autres structures de langage et non pas pour mettre en forme.
Une indentation à quatre espaces est souvent imposé dans les convention de codage de langage comme Java, PHP et Python.
Le 21/08/2020 à 12h36
Justement, je ne comprends pas pourquoi les tabulations ne sont pas la solution idéale où chacun peut régler leur longueur en fonction de leur convenance. Avec des espaces, tu forces l’affichage partout pareil alors que peut-être des gens préféraient des indentations de 2 espaces de longueur dans un codebase de 4 espaces.
Le 21/08/2020 à 12h46
Cherche pas d’où se débat vient, il est sans fin et jamais personne aura raison
Chacun a ses préférences et puis c’est tout.
La seul chose qu’il faut faire, c’est que sur un même projet tous le monde soit d’accord avec l’indentation à utiliser (tout le mondes en espace ou en tabulation).
Le 21/08/2020 à 16h53
C’est justement par ce qu’on a chacun ses préférences qu’interdire les tabulations comme le fait le langage YAML n’est pas très judicieux.
De même que le choix entre tabulation et espaces, c’est ce dernier qui impose à tout le monde la largeur de l’indentation. Alors qu’avec les tabulations, chacun choisi sa largeur, voir peut le changer suivant les circonstances.
Le 21/08/2020 à 17h16
Je répète au cas où ma réponse précédente soit passé à l’as : il n’y a pas de nombre d’espaces imposé dans les indentations YAML. Après, la gueguerre spaces/tab n’est pas trop le sujet de l’article et on a compris la position de chacun, donc si on pouvait passer à autre chose… ;)
Le 22/08/2020 à 01h33
Désolé pour la digression sur le choix du type d’indentation (ou le non-choix concernant YAML).
Mais je pense que vous avez compris que j’utilise principalement des tabulations pour indenter mon code. Donc je suis pas pote avec YAML, ou la plupart des CMS ou frameworks qui utilisent une indentation avec des espaces 😅
Mais merci pour cet article, que je garderai sous le coude pour aider certains collègues à se mettre à git en douceur 😁
Car mine de rien on trouve beaucoup de tuto pour débutants à git, mais cela commence en général direct en ligne de commande. Qui est le plus efficace pour utiliser git, à mon avis, mais qui rebute beaucoup de monde.
Le 25/08/2020 à 21h27
Cela me rappelle trop la scène dans Silicon Valley (Richard contre Winnie)
Le 21/08/2020 à 13h53
Tel que je le comprends, c’est parce que les tabulations ne couvrent pas très bien tous les cas.
La tabulation marche très bien pour l’indentation des blocs, et a l’avantage de permettre à chacun de customiser l’affichage.
Par contre dans une structure type
function beaucoup_d_arguments(param1,
………………………………………………….param3,
………………………………………………….param4,
………………………………………………….param5,
………………………………………………….param6,
………………………………………………….param7
) {
….print(‘toto’)
}
les tabulations ne permettraient pas de garantir l’alignement des paramètres sauf à imposer qu’elles fassent le même nombre de caractères chez tous. Or dès qu’on fait des choses un tout petit peu complexe, la nécessité d’aligner des paramètres pour s’y retrouver est assez courante.
Du coup les espaces son préférables… et comme on n’a pas envie de mélanger des tabulations et des espaces, la convention qui s’est imposée quasi-partout, c’est de n’utiliser que des espaces.
Le 21/08/2020 à 21h14
L’exemple donné confond alignement (des paramètres) et l’indentation (du code). La règle, la vraie, la seule et l’unique, reçue par Moïse dans le désert du Sinaï, dictée par Allah à Mohammed, conçue par Bouddha et révélée par Quetzacoatl est, était, et sera toujours space to align, tabs to indent.
Mais je passe beaucoup de temps à expliquer à mes devs des règles plus importantes qu’il est bien plus simple de dire “me fais pas chier, mets juste des espaces…”
Le 21/08/2020 à 21h49
Faudra que t’en parles à JsLint et consort.
…Mouarf.
Le 22/08/2020 à 07h12
J’utilise un éditeur et un langage sérieux moi Monsieur: vim et Ada 83
Plus sérieusement, pour contribuer à plusieurs projets, le plus costaud, c’est git lui-même. Essayez donc de mettre à jour la partie sur la configuration du client mail pour l’envoi de patch (j’aime la recursivité
). Car les patches ne s’envoient que par mail. Et pas n’importe comment !
Le 22/08/2020 à 01h24
L’exemple que tu montres de la fonction avec un paramètre par ligne aligné le plus à droite c’est tout ce que je déteste (et c’est relativement chiant que clang-format ait ce comportement par défaut car il faut changer plein d’options pour les différents cas). Perso je mets un saut de ligne avant le 1e paramètre et du coup tous les paramètres sont indentés avec la même indentation, par rapport au début du début de la ligne précédente et non de la parenthèse ouvrante.
Ce sont des cas foireux selon moi comme expliqué ci-dessus. Je préfère un guide de style déterministe où je fais +1 indentation et un alignement vers la gauche plutôt qu’un nombre “random” d’espace pour faire des alignements vers la droite.
Le 21/08/2020 à 12h41
Non
Oui, là par contre ça peut être un problème puisque les tabulations ne doivent pas être utilisées selon la spec YAML.
Le 21/08/2020 à 12h48
gitk pour ma part :)
Le 21/08/2020 à 15h14
C’est justement le but. Comme le souligne Zerdligham , tu peux avoir des incohérences d’affichage et autres erreurs de formatage avec les tabulations. Avec les espaces c’est pour tout le monde pareil et il n’y a plus de surprise.
Le 21/08/2020 à 15h20
Oui c’est ce que mentionne la spec YAML (même s’ils acceptent les tabulations pour les espacements hors indentation de ce que j’en comprends)
Le 21/08/2020 à 15h44
merci pour cet excellent article !
Le 21/08/2020 à 16h20
Un outil puissant et incroyablement intelligent malgré ce que sa description et son nom laissent à penser. (en même temps, Torvalds a un humour particulier)
Sinon, outre le concentrateur à gens déplaisants, ou le laboratoire de gens déplaisants, il y a aussi des gestionnaires de repo pouvant être auto hébergés très simples comme Gitea. (GitLab aussi, mais c’est une arme nucléaire si on veut juste des repos à interface graphique…)
Gitea a une interface similaire à l’ancienne de Github, rapide à prendre en main. Pour du geekage perso c’est sympa.
Le 21/08/2020 à 16h23
Oui on en parlera (mais plutôt côté NAS, et ce n’était pas trop le sujet de ce papier :p)
Le 21/08/2020 à 21h31
Je me doutais bien que vous en auriez parlé ultérieurement, j’ai juste souhaité évoquer ça pour ceux auraient la curiosité en avance de phase. (d’ailleurs ça m’a étonné de ne pas avoir vu de “Github c’est Microsoft donc c’est mal m’voyez”, le shitstorm tabulation/espace a du prendre le dessus, bien joué
)
Après à titre perso j’en ai pas testé 36 non plus, j’ai de l’expérience avec Github (car utilisé par diverses clients), un peu aussi avec Gitlab pour les mêmes raisons et parce que je l’avais testé à titre perso, et Gitea dernièrement pour le remplacer.
Le 21/08/2020 à 22h05
Oui c’est toujours le risque avec ce genre d’article. Après on fait au plus simple pour un public néophyte avant tout, ce qui n’empêche pas de parler d’autres solutions. Surtout que GitHub reste la plateforme de référence, intégrée dans tous les outils du marché. Puis bon, il était déjà mal vu de certains même avant le rachat par Microsoft
Le 21/08/2020 à 18h35
Quand on écrit une méthode/fonction avec plein de paramètres c’est qu’on a foiré quelque part. Passer un seul objet/tableau est plus court et met donc au placard ce genre de besoin d’alignement.
De la manière dont tu le dis on dirait que tu décris une fatalité. Clarifions : le problème ne vient pas de l’affichage mais de la façon d’afficher qui est de la responsabilité du logiciel. Il n’y a pas vraiment de “protocole” bien établi sur le sujet. C’est de là que vient le nœud du problème qui a des ramification internationales.
L’écriture (la façon d’écrire) diffère en bien des points d’un pays à l’autre. ex: Le retrait sur un début de paragraphe présent ou pas puis avec ou sans tiret. On utilise en France ‘«’ dans un texte américain le “ (double quote) sera déjà pas mal. Faudra pas en demander plus. Il y a nombre d’autres subtilités. C’est un peu comme “letter box” vs “mail box”.
Autrement:
Je trouve assez ironique de voir que la tabulation est placardée comme mauvaise pratique par des faiseur (ou malfaisants) de FrameWork / Language qui passent leur temps à réinventer la soupe (souvent un moins bien) et de pondre des règles de nommage qu’ils n’appliquent pas eux même dans leurs exemples de code. Doh!
Le 21/08/2020 à 22h07
Bel article!
GIT… Perso, c’est de loin l’outil qui a le plus amélioré mon quotidien de developpeur depuis que je bosse. Impossible de revenir en arrière une fois qu’on y a pris goût.
Le 21/08/2020 à 22h08
Même pas un petit retour sur SVN ?
Le 21/08/2020 à 22h18
Même pas dans mes pires cauchemars 😅
Depuis git, tous les cvs/svn/clearcase/sourcesafe/… => poubelle. C’est vraiment un des rares domaine où il y a un tel consensus.
Le seul concurrent qui apparemment trouve grâce auprès de certains, ce serait mercurial. Mais perso j’ai jamais utilisé.
Le 22/08/2020 à 06h31
Écrire du yaml
Le 22/08/2020 à 09h45
Pour naviguer entre pas mal de langages /formats, je pense qu’il faut surtout comprendre une chose : différentes manières de faire existent, on en apprécie plus ou moins certaines, on en déteste plus ou moins d’autres, elles sont toutes le résultat de choix de design.
Il y a des trucs que je trouve profondément débiles dans HTML ou même dans Markdown (d’où les 200 dérivés), ou JSON, etc. Je fais avec quand je n’ai pas le choix. Sur mes propres projets, je fais selon mes critères qui se retrouvent de fait imposés aux autres (notamment les utilisateurs/contributeurs). Certains plairont, d’autres non. Ainsi va la vie, un choix ne plait jamais à tous, c’est le principe.
Mais je pense qu’être développeur, notamment lorsque l’on touche à l’open source, demande d’une certaine manière d’être ouvert d’esprit. Je comprends que l’on puisse se battre contre des contraintes réelles (vous devez utiliser tel outil par exemple). Même parfois les guerres de chapelles qui occupent des heures à brasser du vent sans générer d’électricité (du genre open source/libre).
Mais alors il ne me viendrait franchement pas à l’idée de me préoccuper du fait qu’un format me demande d’appuyer sur la touche espace plutôt que la tabulation (ou l’inverse). Je vois bien la position de principe (préférence de tabulation par rapport à espace). Mais de là à en fait un critère de choix de participation à tel ou tel projet (sans que même une contrainte de nombres d’espaces ne soit imposé) comme si ça avait quelconque incidence… j’avoue que ça me dépasse.
Le 22/08/2020 à 10h51
Je ne limite pas mes choix à cause des indentations avec espaces, je fais avec quand se sont des projets autre que les miens.
Mais pour prendre un exemple, quand j’utilise Symfony et que je crée les différents contrôleurs (ou entitées) via la ligne de commande, qui permet de gagner beaucoup de temps, les fichiers sont créés avec des indentations avec espaces.
Heureusement la plupart des IDE permettent de changer les espaces en tabulation rapidement, mais c’est une étape que j’aurais préféré éviter 😋
Après, je vais sûrement en faire sourire certains, mais mine de rien utiliser des tabulations au lieu d’espaces est une manière d’être plus écologique. Car un seul caractère par ligne au lieu de quatre, cela réduit le poid du fichier et donc son empreinte écologique 😏
Le 22/08/2020 à 10h53
Après faut dire aussi que t’utilise les espaces ou les tabulations pour indenté, tu appuie quand même sur la touche de tabulation, et ton IDE s’occupe de mettre ce qu’il faut où il faut
.
Avec un IDE correcte, tu te rend même pas compte si t’est sur des fichiers avec indentation en espace ou tabulation, et au sein d’un même projet il devrait être capable de gérer différentes indentations pour différents fichiers.
Le 22/08/2020 à 13h59
Yep, Visual Code a généralement assez d’intelligence pour adapter l’indentation aux spécificités du langage utilisé. Perso j’utilise tabulation sans réfléchir, l’outil fait le reste.
Ce qui permet de se concentrer sur une action a une meilleure valeur ajoutée que de se demander si c’est une tabulation ou 2,5 espaces.
Le 22/08/2020 à 11h17
Pour tout ce qui est formattage de code (tab/espaces, alignement de params, saut de lignes après les conditions ou pas, etc. etc.), quand je bosse sur des projets qui ne sont pas les miens, j’utilise deux configurations de mon outil de formattage:
Résultat : je fais ce que je veux quand je code, et tout est aux normes attendues quand c’est soumis. :)
Le 22/08/2020 à 15h42
Si l’outil est open source et accessible en commande, je ne comprends pas pourquoi il faut créer un compte sur Github ? Pourquoi on ne peut pas le “forker” sur gitlab, ou autre ? “Le service est gratuit”, j’ai un peu de mal avec cet argument, il a tendance à me faire freiner qu’à me convaincre d’y aller.
Le 22/08/2020 à 17h05
Tu peux parfaitement. C’est juste qu’en créant un compte sur GitHub, tu pourras le faire depuis l’interface web, ce que tu ne peux pas faire si tu changes de plateforme (ou alors propose une évolution ou un patch/plugin à GitLab/Gitea pour avoir un bouton pour ça).
Il me semble que le but du tuto ici présent était de montrer ce qu’on pouvait faire simplement.
Le point supplémentaire quand le fork reste sur la même plateforme, c’est que les forks sont tracés, ce qui permet parfois de trouver celui qui a déjà fait un patch (pas encore intégré upstream) pour le problème que tu as vu ou la fonctionnalité qui te manque.
Le 22/08/2020 à 19h55
Parce que si c’est ce que tu veux faire, ce tuto ne s’adresse pas à toi (mais bon, fallait bien qu’on en ait un pour faire la remarque, voir les échanges précédents ;))
Le 23/08/2020 à 09h53
C’était une simple question. Je n’ai jamais dit que je voulais un tuto personnalisé…
Décidément, ça devient difficile de faire une remarque ou poser une question sans se faire rembarrer.
Le 23/08/2020 à 11h04
La question était tout sauf innocente, mais libre à toi de faire comme si de rien n’était ;) D’autant que le pourquoi du choix de l’interface en ligne et la simplicité que ça apporte ici sont expliqués dans l’article (je l’ai évoqué aussi dans les précédents commentaires).
Notamment parce que sur ces sujets, on a assez de bouteille pour anticiper le trolling (Microsoft, GitHub, CLI, etc.). Et comme toujours, je réponds à tout le monde lorsque c’est nécessaire, il n’y a rien de difficile à ça. J’adapte simplement ma réponse aux questions/remarques.
Le 23/08/2020 à 11h51
Il n’y a que toi qui y voit du troll, c’était une vraie question. Jje ne pensais pas être catalogué comme trolleur anti-Microsoft, à moins que parler d’un produit Microsoft nous fasse immédiatement entrer dans cette catégorie ? Gitlab est aussi cité, mais ensuite dans le pas-à-pas on lit “créez un compte github”, donc la question me paraît légitime, il n’est pas indiqué qu’on peut créer un compte ailleurs, j’ai eu l’impression que c’était obligatoire. Git est toujours présenté comme décentralisé (donc agnostique de la plateforme), à la différence de svn par exemple, qui impose la connexion au dépôt, donc je ne comprenais pas le lien avec un compte Github. C’est un peu comme si dans un article présentant le format .torrent, on disait “ensuite créez un compte sur The pirate bay”, je demandais juste si c’était un passage obligé ou s’il y avait une alternative.
Si ces questions t’agacent, et que si tu considères qu’une question est forcément un troll, je comprends mieux le ton de la réponse. Dans ce cas là inutile de répondre, il vaut mieux laisser les autres lecteurs le faire, comme Triton l’a fait de manière plus intelligente. Ta “bouteille” biaise visiblement ton jugement.
Le 23/08/2020 à 17h52
Non, c’est surtout que lorsqu’un commentaire profite d’une question vague pour cocher toutes les cases du bingo trolling d’un papier sur Git/GitHub, j’ai plutôt tendance à y voir de la malice. Surtout quand tout est déjà mentionné dans l’article en question (notamment ce que te répond Triton). Les questions ne m’agacent pas, j’interviens régulièrement justement parce que c’est utile.
Mais comme dit dans mon précédent message, je sais que de telles interventions sont une sorte de passage obligé sur ce genre de papiers. Comme les batailles OSS/Libre quand on traite de ce sujet et autres guerres de chapelles régulières. Je m’en désole plus qu’autre chose. C’est la vie.
Comme expliqué dans l’article et dans mes réponses, j’ai montré ici un exemple facile à reproduire pour n’importe qui, de ce qu’est une PR (donc une participation à un projet open source). L’idée était de proposer une manière simple de faire (donc sans CLI, sans logiciel à installer). Et donc via une plateforme en ligne qui efface de nombreuses contraintes dans la manière de faire.
Pour les méthodes plus classiques/lourdes, on verra plus tard. Là j’ai surtout évité de faire un x2 sur le taille du papier, ce qui l’aurait au passage rendu imbitable, juste pour éviter la création d’un compte gratuit qui n’engage à rien (ce que personne n’est d’ailleurs obligé de faire).
C’est aussi pour cette volonté de simplicité que je suis parti sur un projet de participation à un dépôt de manifestes YAML que du code. Parce que ça m’évite d’avoir à donner des cours de JS au passage.
Je ne comprend pas trop ton // avec TPB par contre, il n’y a pas vraiment de rapport. Le fait que Git soit décentralisé n’empêche pas une multitude de clients d’exister. GitHub, comme d’autres plateformes du genre, a l’intérêt d’être un gestionnaire de dépôts en ligne en même temps qu’un client web. C’est ce qui faisait son intérêt ici (de mémoire, TPB n’est pas un client BT).
Le 22/08/2020 à 15h51
Yeah, le coup de taper des espaces ou des tabulations, au mieux tu respires un bon coup et tu t’adaptes (il faut savoir être un minimum conciliant dans la vie, sinon tu dois être une plaie pour ton entourage…), au pire tu configures ton IDE (ou un plugin Vim/VSCode…), lequel fera tout ce qu’il faut pour toi, en particulier remplacer une tabulation malheureusement insérée ans un yaml, “afficher” (sans remplacer) 4 espaces par 2 espaces, faire un joli alignement, etc. Aujourd’hui certains outils sont hyper évolués, tu fais à peu près ce que tu veux.
Donc si tu rages sur un pb de rendu du code, c’est que ton outil a besoin d’être configuré pour te convenir, c’tout ;)
Puis bon, un développeur passe plus de temps à lire de la doc, discuter et réfléchir qu’à coder. Donc tout ça me semble bien superficiel.
Le 22/08/2020 à 15h57
Aussi, si tu insères une tab au lieu d’un espace dans un yaml, si ce dernier dispose d’un schéma (y’en a pour plein de technos et projets), alors ton IDE indiquera qu’une variable est inconnue. Si ça ne le fait pas, c’est que tu n’as pas bien configuré ton IDE, pas que tu as tapé une tab
Le 23/08/2020 à 06h27
On en revient à l’interface chaise/clavier dans tous les cas !
Le 23/08/2020 à 08h36
Merci pour l’article ! J’ai trouvé ça très intéressant ! Par ailleurs vous les commentaires et ta réponse @David, ça m’a permis d’apprendre que le Yaml n’imposait pas spécialement 4 espaces mais juste “plus d’espaces d’indentation que le noeud parent” alors que j’aurai juré que c’était 4 obligatoirement… :)
Vivement la suite !
Le 23/08/2020 à 08h59
Oui c’est une croyance commune, qui a la vie dure (je ne sais pas trop d’où elle vient d’ailleurs parce qu’aucun outil que je connais n’impose ça).
Le 24/08/2020 à 08h37
Mon plus gros problème avec Git et les PR c’est que pour beaucoup de petit projets, il n’y a pas de “maintainer” qui s’occupe de trier les “issues” et les “pull requests” qui arrivent, laissant souvent un nombre conséquent en souffrance. Juste un développeur qui fait son code de son côté. Donc on perds le principal intérêt de git.
Maintenant je “fork” de plus en plus des projets sans faire de “PR” vers l’“upstream” vu qu’ils ne sont pas “reviewés”. J’intègre les modifications de l’“upstream” de temps en temps pour suivre l’évolution, pas plus. Eventuellement quelqu’un viendra prendre mon code plutôt que l’“original”.
Il est très lourd d’effectuer une modification puis d’attendre x jours/semaines qu’elle soit éventuellement acceptée pour pouvoir continuer à travailler sans devoir gérer une dizaine de conflits au moment du “merge”.
Le 24/08/2020 à 09h24
Oui c’est un des soucis je pense, de ne pas pouvoir faire ses modifs, les proposer, mais continuer à bosser sur le projet forké en //. Mais c’est un problème structurel, pas tellement du fait de Git. Ce serait la même chose si les PR étaient rejetées par exemple.
Le 24/08/2020 à 11h10
Qui oserais rejeter mes PR !
Après, cette expérience m’a fait comprendre l’intérêt d’un maintainer tel que Torvalds sur le noyau Linux, qui valide les PRs mais ne fait pas obligatoirement des tests fonctionnels dessus, il donne la direction du projet.
Après je n’ai pas une expérience très longue avec Git/gestion de versions, mais je trouve que dans l’univers de Git, le rôle du maintainer (ou un autre rôle semblable) n’est pas assez présenté et son importance peut rester flou pour certains.
Peut-être que certains vont trouver que mes propos vont à l’encontre d’un esprit “équipe” mais je pense que nommer un responsable bien identifié dans une équipe, qui aura pour charge pendant une période donnée de diriger le projet en fonction d’une orientation décidé à plusieurs.je m’emporte, ça dépends de la taille des projets. bref…Le 24/08/2020 à 11h26
C’est quelque chose qu’il m’arrive de répéter parfois 4 ou 5 fois en une journée au boulot : c’est pas de la technique mais de l’orga.
Quand le projet commence à prendre de l’ampleur, il devient naturel et même obligé de déléguer les tâches de triage et d’analyse d’issues / PR (une personne ne peut pas tout faire, comme tu cites avec l’exemple de Torvalds) à des personnes pour ça.
Après le hic, c’est comme ce que je citais dans mon message sur l’article de la contribution au libre : si le mainteneur / développeur est une Diva qui refuse tout avis extérieur (et il y en a, et tu te fais pourrir parce que tu oses relever une erreur ou suggérer une amélioration dans son Sacro Saint Divin Code, Béni d’entre tous et Elu de la Prophétie), la meilleure solution restera le fork comme tu le fais. C’est comme ça que certains projets devenus les “main” sont nés il me semble, mais j’ai pas de nom en tête.
Du côté des mainteneurs peu réactifs ou solitaires, il me semble que c’est ça qui avait porté préjudice à OpenSSL lors de la faille Heartbleed, bibliothèque utilisée par plein de monde mais code très peu audité à l’époque, ce qui aurait pu révéler la faille.
Le 26/08/2020 à 08h12
Merci de ton retour. Après je trouve que Torvalds s’en sort bien sur le kernel avec très peu de “drama” par rapport à la quantité de PR qu’il doit gérer. (mais je ne connais pas dans les détails).
Sinon dans les exemples, j’aurais envie de dire OpenELEC/LibreELEC/CoreELEC, plus les deux premiers que le troisième, mais OpenELEC est (afaik) proche de la mort. Le site ne référence que RPI 1 et 2 par exemple.