Philippe F a écrit 2202 commentaires

Pour l'instant, Multigit a surtout été utilisé par des gens qui souffraient beaucoup du problème qu'il résout, et ont compris tout de suite comment ça marchait.

Mais ta remarque est bonne, un petit guide de démarrage serait le bienvenue. C'est pour ce genre de retour que j'ai posté l'annonce ici.

Je rajouterai ça dans la prochaine version.

Alors, on est d'accord mais j'ai du mal à suivre le fil de ta pensée.

J'explique dans la dépêche qu'on utilise des dépôts séparés pour gérer des droits d'accès car git ne le permet pas au sein d'un repo.

Dans ton premier commentaire tu me dis en gros "sisi, c'est possibles avec des hooks et une branche dédiée".

Ce à quoi je te réponds en gros "non, ou alors je vois pas comment". Et là tu me réponds que "ça sert à rien si on utilise Multigit".

Bref, je saisis pas ce que tu voulais dire dans ton premier commentaire.

Sous git, je ne sais pas comment on peut autoriser la lecture d'un certain répertoire d'un dépôt à une équipe seulement et interdire à toutes les autres personnes d'y accéder. Sachant que ledit répertoire doit rester sous git pour être géré dans le projet comme le reste.

Peux-tu expliciter ta solution ? Pour moi, c'est impossible, git n'a pas été conçu pour interdire des accès à une partie d'un dépôt.

J'accepte les PR !

Mais c'est une bonne remarque, j'avais pas imaginé que ce point ne serait pas clair. Je rajouterai quelque chose dans le README au moins, voire dans un semblant de documentation un jour.

Ok, l'hébergement en Europe sera à part de l'infra US et monde dans ce cas.

Mais les employés de AWS Europe sont bien assujetis via leur maison mère à AWS USA et donc à Trump. Si Trump demande de couper le contact, ils seront devant un conflit moral mais rien ne permet d'être sûr qu'ils choisiront les intérêts de l'Europe plutôt que ceux des Etats-Unis.

Quand je parle de droits d'accès, je parle d'interdiction de lecture. Il ne me semble pas que ta proposition résolve ce problème, j'ai l'impression que tu me parles plus de protected branch.

Surtout que les git hooks, ça doit être installé manuellement pour fonctionner, donc tu n'as pas de garantie que tout le monde aie la même configuration de githook.

C'est possible de définir un "top repo" qui contiendra tous les autres dépôts, y compris par exemple le fichier multigit décrivant la liste de tous les autres dépôts du projet. Ca te donne un workflow un tu clones le top dépôt avec git naturellement, puis tu récupères le fichier multigit pour cloner tous les sous-dépôts.

D'un point de vue multigit pur, il n'y a pas de notion de "top repo", il y a juste un répertoire qui contient un paquet de dépôt multigit avec un niveau d'imbrication quelconque. Notamment, tu peux tout à fait avoir une hiérarchie complexe:

• project directory
  • repo 1
  • subdirectory
    • repo 2
      • subrepo 2.1
      • subrepo 2.2
    • repo 3

Multigit va scanner le répertoire project recursivement pour identifier tous les dépôts git qu'il contient.

Tes dépêches sont toujours un plaisir à lire. Je reste impressionné par la quantité de travail que vous fournissez sur ce jeu et votre attention aux détails!

Oui, l'outil est très orienté "dev au quotidien" et couvre des aspects très pratiques comme créer une branche identique sur 10 dépôts différents répartis au hasard de ta hiérarchie de dépôt.

Il est envisageable de gérer également les sous-modules dans le futur dans Multigit. Voire de permettre la transition entre l'un et l'autre mode. On verra si la demande se concrétise un peu plus.

Je suis pas mal amené ces derniers temps à coder dans des langages où je suis débutant, voire ignare (powershell, C#, groovy). Dès que je comprends rien au langage, je demande à l'ami félin-malodorant. Je pourrais trouver la même réponse soit en lisant une doc spécialisée qu'il me faut d'abord trouver, puis en analysaer mon besoin et la comparant à ce qui est proposé en faisant mon chemin avec l'information que je cherche. Bref, elle fait en 20 secondes ce qu'il me faudrait 5 minutes à faire.

Idem pour des points de documentation précis, elle remplace un bon stackoverflow. Même dans mon domaine d'expertise (Python) où je connais la doc à moitié par cœur et où je suis capable de trouver le chapitre qui m'intéresse en une dizaine de seconde, c'est légèrement plus rapide de demander à l'IA.

Ce qui est proprement flippant, c'est que du coup en tant que débutant, je peux trouver des réponses qui demandent pas mal d'expertise (lire en claire en secure string en powershell). Plus besoin d'être expert pour produire de l'expertise.

L'humain choisissant toujours la voie avec le plus de confort, je me pose la question de qui va encore vouloir devenir expert dans un domaine ? Comment rivaliser avec les faux experts qui résolvent aussi les vrais problèmes. La différence se fera sur les problèmes relativement complexe, où il faut de l'expertise et du recul. Mais si on sollicite un expert, c'est justement qu'on a ni l'un ni l'autre.

Merci, ça fait plaisir de voir que l'outil a un sens dans d'autres organisations que la mienne!

Sur les interdépendances de librairies auxquelles tu dois pas toucher parce que tu risques de casser le projet d'un autre, mais que tu dois quand même modifier parce que t'en a besoin dans ton projet… on a exactement la même.

En théorie, on a résolu ça avec du gitflow, et des branches stables. Sauf que la définition de "stable" est très subjective. Stable, ça veut dire que ça casse pas mon projet. Mais j'ai aucun moyen de savoir si ça a cassé un des deux autres projets qui utilisent la même lib. Les trois projets sont bien sûrs en pression temporelle max, sans aucune marge de manoeuvre pour débugger un truc qui ne concerne pas directement le client.

On a proposé au management de mettre de la CI sur des projets de référence qu'on ne doit jamais casser mais ils ont refusé: ça coût trop cher d'avoir des intégrateurs qui feraient juste ça. Mieux vaut casser les projets de façon aveugle et les réparer à l'arrache, ça marche déjà très bien comme ça.

(je forcis un peu le trait, dans faits, on s'en sort mais il y a toujours un moment où tu es dans une zone aveugle en terme de modifications)

Je dirais pas que ça apporte en plus, c'est une approche différente:

• on continue à utiliser des commandes git contrairement à repo qui utilise une nomenclature différente: sync, upload, … . Pas besoin d'apprendre un nouvel outil et une nouvelle façon de fonctionner

• il y a une interface graphique qui permet de repérer visuellement plus facilement l'état global d'un projet et d'agir facilement sur un sous-ensemble de dépôts

Merci, je trouvais plus le nom de l'autre solution que j'avais regardé. Je l'ai rejetée pour les mêmes raisons, elle introduit de la complexité par rapport aux commandes git classiques et ne permet pas d'interaction graphique simple.

Par contre, l'intérêt des sous-modules, c'est que le commit est ajouté à un commit du dépôt parent comme cela tu garantie que la dépendance est dans la bonne version.

On fonctionne plutôt avec des conventions: l'ensemble des dépôts doit être fonctionnel et stable sur la branche principale (dev chez nous) à sa dernière version. Pour introduire des changements, on va passer par des "features branch" (le git flow quoi) et quand elle est stable, on va merger toute ces branches dans dev. Et au moment où on appuie sur le bouton git push, on publie.

Il y a bien quelques secondes par jour où tu risques de tomber sur une dépendance désynchronisée, mais notre niveau d'activité est suffisamment faible pour que ça n'arrive jamais en pratique. Et même si ça arrivait, tu relances un git pull et tout retombe dans l'ordre.

C'est pas tellement distinct de la façon font fonctionne n'importe quel dépôt git, la branche principale doit être stable

Oui, depuis quelques années, il y a pas mal d'outils qui fleurissent en ligne de commande pour gérer tout cela. Il y en avait un déjà quand j'ai commencé, c'était repo fourni par google pour Android.

De mon côté, j'ai peu développé l'aspect ligne de commande parce que c'est pas là où il y avait des besoins. Cela dit, ça revient lentement.

Pour le "bootstrap" d'un projet, deux approches possibles:

• la plus simple : un développeur crée l'arborescence de dépôt dont il a besoin sur son poste. Multigit va découvrir tous les dépôts et il pourra exporter le fichier multigit pour ses camarades

• le plus geek: tu prépares à la main le bon fichier multigit en JSON que tu refiles à tes camarades.

Dans les deux cas, chaque projet est défini par un fichier multigit que nous partageons dans un lieu central. Chacun va ensuite faire "clone from multigit file" et se retrouver avec un projet prêt à l'emploi.

Une autre fonction qui a été demandée et qui est bien pratique, c'est de mettre l'ensemble des dépôts dans le même état exact que celui de son voison, ou celui qui est sorti de la CI. C'est "Apply multigit file"

Pour ton segfault, c'est pas cool. Tu peux me contacter en privé stp à phil.fremy at free.fr ?

J'ai essayé les sous-modules ainsi qu'une ou deux autres solutions mais je les ai rapidement rejetées par rapport à mon contexte. En effet :

• mes collègues utilisent exclusivement une interface graphique pour interagir avec git (TortoiseGit majoritairement). A l'époque où j'ai écrit Multigit, aucun client git graphique ne fournissait une gestion des sous-modules. Pour eux, ça n'auraient pas été utilisable.

• les sous-modules demandent un apprentissage nouveau au dessus de git. Les commandes n'ont pas les mêmes noms, et il y a des opérations en plus à effectuer. Une grande partie de mes collègues (surtout il y a 4 ans) étaient déjà à la peine avec l'utilisation de git toute simple. Mon objectif est de leur simplifier la vie, pas de la leur rendre plus complexe.

• comme le décrit si bien AncalagonTotof, avec les sous-modules, on peut se rater. Ça offre encore plus de façon de se planter avant d'arriver à un résultat attendu. Notamment, il faut être très attentif au répertoire dans lequel on lance sa commande car le résultat peut n'avoir rien à voir.

Mon objectif en écrivant Multigit était vraiment la simplicité pour tout le monde:

• pouvoir d'un coup d'oeil identifier les 7 dépôts modifiés parmi les 67 dépôts du projet et prendre quelques secondes pour vérifier le diff sur chacun

• pouvoir faire les opérations du quotidien sur tous les dépôts ou un sous-ensemble de dépôt de façon très simple

• utiliser uniquement des commandes git standard, visibles dans le log, de façon à ce que tout le monde comprenne ce qui se passe

D'après mes collègues, j'ai plutôt réussi ma mission. Et je suis tout fier quand je vois qu'il est sur tous les écrans des développeurs de mon boulot.

Cela dit, si les sous-modules marchent bien pour vous, continuez avec. J'ai aussi deux collègues (sur 300) qui en sont très contents et m'ont demandé d'en rajouter le support dans Multigit. J'attends d'avoir plus de demande avant de me lancer

Un truc que les sous-modules font de façon élégante, c'est l'atomicité: un changement sur plusieurs dépôts n'est réellement publié qu'après la mise à jour de dépôt parent. C'est cool, sauf que dans nos projets, on a jamais eu de problème d'atomicité. Par contre, on a très souvent eu des modifs oubliées parce qu'elles étaient dans un dépôt profond que le développeur avait oublié qu'il avait modifié. Et pas mal d'autres problématiques liées uniquement au fait que quand on manipule beaucoup de dépôts, on a vite fait d'en rater un.

Je travaille dans le domaine des logiels pour carte à puce. Ces softs doivent être sécurisés contre des attaques "externes", où le flot du code ne suit pas ce qui est prévu par le source C ou assembleur. On rajoute donc pas mal de contre-mesure pour s'assurer qu'on ne sort pas du chemin officiel du code (double-vérifications, flags qu'on monte à des points stratégiques du code, ordonnancement particulier, valeurs particulière, …).

Une des difficultés qu'on rencontre est celle que tu décris ici dans ton article: le compilateur pense naïvement que le code s'exécute comme il le voit, et va avoir tendance à retirer certaines contre-mesures. On bidouille à coup d'assembleur, de volatile, de pragma mais ça suffit pas toujours. Et surtout, assez non-prédictif. Il va décider tout un coup de retirer une contre-mesure qu'il gardait auparavant. On passe donc la version finale de notre code à une moulinette intense pour vérifier la présence des contre-mesures.

Avantage par rapport à toi: on ne cible qu'une plate-forme à la fois

Moi je vote 3 mais je vais tester pour être sûr.

Python recèle bien des surprises quand on le chatouille un peu.

Je me souviens d'un PyCon où qq'un proposait ce genre de challenge:

Quelle est la valeur retournée :

try:
    return 1
finally:
    return 2

Variante :

try:
    raise ValueError
    return 1
except ValueError:
    return 2
finally:
    return 3

D'ailleurs, je ne me souviens plus de la réponse et je suis bien en peine de la trouver de nouveau sans un test…

C'est très personnel évidemment, mais il y a plusieurs raisons pour lesquels je n'utilise pas les clients git intégrés dans PyCharm ou StudioCode .

Il y a un côté charge mentale / mood spécifique. Quand je suis dans mon IDE, j'écris ou je debug du code. Quand je suis dans mon client git, je m'occupe de la partie archivage / lien avec mes collègues. La séparation des outils me permet de mieux séparer les tâches dans ma tête et rester plus concentré. Quand je fais un Ctrl-Tab dans mon IDE, je veux basculer entre les deux derniers sources que j'étais en train d'éditer. Ca me bourre de tomber sur une fenêtre de diff ou de commit parce que j'ai interagi avec git entretemps.

La deuxième raison, c'est qu'un IDE est déjà très encombré en terme de visuel. Ma concentration est affectée par la quantité de choses que je dois interpréter à l'écran. Trouver les fonctionnalités liées à Git au milieu du fratras qu'est un IDE, ça me coûte en effort, c'est pas agréable pour moi. A l'inverse un client git dédié va souvent avoir une interface simple, minimaliste et focalisée sur la gestion git. Parfait! On parle de nouveau de charge mentale ici.

Une raison connexe, c'est que un historique git et des commandes git, c'est un sujet complexe. Mieux vaut avoir le maximum d'espace de visualisation pour intervenir là-dessus. Même pour un commit de trois fichiers, je veux être sûr de voir le diff exacte sur les trois fichiers pour ne pas pousser de la merde et écrire un message de commit approprié. Et quand il s'agit de faire des recherches complexes dans l'historique, de comprendre comment un changement a disparu, ou quelles sont les branches en cours qui ont besoin d'être réintégrées, je suis content d'avoir un maximum d'espace de visualisation et pas 100 pixels en bas ou à gauche de mon code.

Cela dit, une fonction git / IDE que j'aime bien et qui est absente d'un gestionnaire pur git, c'est sous PyCharm: show git history for selection. Ca te montre tous les commits qui ont affectés tes 10 lignes de code selectionnées. C'est du git blame++ bien présenté et très pratique.

Tu ne tiens pas assez courant de l'actualité, il parait que maintenant, linkedin sert à faire du dating

A quand le swipe pour choisir un boulot en fonction de la tête de ton chef ?

Oui, il me semble qu'il y a aussi une notion de délai. Genre ton commentaire va apparaître 1h plus tard. Ca limite les ping-pongs qui font monter l'énergie trollesque!

J'entends toujours cet argument, mais je ne saisis pas en quoi c'est un plus.

Parmi tous les trucs qui sont branchés sur mon réseau domestique, j'en ai un seul qui de temps en temps pourrait être adressé de l'extérieur. Tout le reste est bien mieux derrière un mur de flamme géré (sûrement imparfaitement) par ma box.

L'IPv6, c'est un peu comme inviter les gens à se téléporter directement chez toi sans passer par la porte d'entrée finalement. Et moi, j'aime pas trop faire rentrer n'importe qui…

Ma grosse boite (IDEMIA, 15 000 personnes) a validé la publication d'un soft développé en interne sous APL. Les choses bougent…

ils ne s'activent pas de la même façon sous Linux et sous Windows

Pas faux ; cela dit, de toute façon, l'activation doit être différente

Mon cerveau arrive bien à gérer la charge mentale de faire source plutôt qu'un appel direct, mais le script vs bin, il y a toujours un moment où je me maille.

ne permet pas de créer un lock file unique pour toutes les plateformes

Carrément. Ce qui fait que c'est vite lourd. J'imagine qu'en théorie, je devrais avoir un windows-req.txt et un linux-req.txt qui tous deux viseraient un common-req.txt . Mais je ne suis pas sûr que ça survive correctement une mise à jour des dépendances Clairement, je ne suis pas assez familier avec l'outil. Je devrais lire plus de doc sur le sujet… mais il me semble qu'elles sont aux abonnés absents. Tous les tutos partent du principe que tu es sur une seule plate-forme, linux dans 99% des cas.

Au final, comme je target du linux en développant sous Windows, je commit la version linux et je garde une modif locale sous Windows qui me pète à la gueule au moins une fois par mois. Pas idéal, mais pas grave. Et une fois par an, j'ai une version des requirements Windows qui part dans le build de la prod. Comme c'est un truc que je fais très rarement, je finis par oublier tous les pièges possibles.

Attention, au nom trompeur de PyInstaller, ce truc génère un .exe , pas un installeur. Le paragraphe de la dépêche est un peu ambigu sur le sujet.

PyInstaller, je comprends qu'on lui reproche beaucoup de choses, mais pour moi, ça marche super bien depuis des années. Beaucoup mieux qu'avec son prédécesseur (py2exe). Ca reste quand même une bonne idée de faire une passe de nettoyage sur les DLL et modules python inutiles après la génération du .exe pour réduire la taille du truc final. Surtout qu'avec du PyQt / PySide, ça grossit très vite (cf mon journal sur le sujet )

Après PyInstaller, un petit coup de InnoSetup et le programme s'intègre parfaitement dans un environnement Windows.

Une petite blagues des environnement virtuels quand vous faites du code portable, c'est qu'ils ne s'activent pas de la même façon sous Linux et sous Windows. Ce serait trop simple, il était essentiel de changer \bin ou /scripts pour passer de l'un à l'autre.

Autre blague des projets portables, les "lock file" qui peuvent ne pas être identiques sous Windows et sous Linux (dependance à mariadb par exemple), sauf que c'est absolument pas géré par le format ni par les outils. C'est juste la m***** en fait.

Le C et le C++ plus simple que Python ? Je vais rebondir sur le bon troll en ce vendredi.

Evidemment, il y a plusieurs définitions de simple…

• Simple pour installer des dépendances: c'est très simple en Python, c'est même le sujet de la dépêche. En C/C++, ce n'est pas simple (sans être particulièrement complexe). Il n'y a pas de convention sur où placer du code externe, la façon de linker une dépendance est très compilateur/platforme dépendante. Et il n'y a pas de dépôt centralisé pour trouver une dépendance. Par exemple, si je veux trouver une lib C qui fait des requêtes http asynchrones, je ne suis pas sûr de savoir où chercher. Et quand je l'aurai trouvé, il me faudra plus qu'une seule ligne de commande pour commencer à l'utiliser.

• Simple pour faire du code multiplatforme: non, les outils de dev vont changer d'un OS à un autre, alors que Python reste unifié.

• Simple du genre il y a pas de pièges dans la syntaxe: non, le C/C++ est truffé de possibilités de te tirer une balle dans le pied, que ce soit dans la syntaxe ou dans le runtime. Python en réaction a limité beaucoup de ces chausse-trappes.

• Simple du genre grammaire simple: pour le C++, je crois pas que quiconque puisse revendiquer que sa syntaxe est simple. Pour le C vs Python, j'aurai tendance à penser que Python reste plus simple à parser. Sachant que pour parser du C, il faut aussi parser un second langage qui est le préprocesseur. Tu as donc deux parseurs fondamentalement à écrire pour parser ce langage. Et en tant qu'humain, tu as deux parseurs à faire tourner dans ton cerveau.

Honnêtement, je suis assez surpris que tu puisses trouver le C simple à apprendre. J'avoue que quand je dois manipuler des tableaux de pointeurs de fonctions qui retournent des pointeurs, je suis à la ramasse sur comment mettre mes * et je pense pas être le seul. Python a une complexité grandissante au fil des années, mais ça reste à mon sens plus approchable.