Journal Assistant de projet logiciel

Posté par  (site web personnel) . Licence CC By‑SA.
Étiquettes :
9
17
mar.
2015

Cher Journal,

je souhaite de présenter Anvil 0.3.0 un petit assistant de projet logiciel fonctionnant avec git, qui te propose:

  • de réécrire l'historique d'un projet en éliminant les espaces avec anvil_whitespace.
  • de réécrire l'historique d'un projet en convertissant les textes en UTF-8 avec anvil_encoding.
  • de réécrire l'historique d'un projet et de renommer les fichiers en utilisant un script sed avec anvil_sed.
  • de prescrire des règles sur les espaces, les mots-clefs SCM (comme $CVS$) et les noms de fichiers grâce à un pre-commit hook.

Il y a aussi quelques fonctionnalités un peu moins robustes, notamment une commande git releng qui permet de préparer de nouvelles versions en se basant sur le cycle suivant:

  • pour préparer la version NEXT on coupe une branche releng/NEXT à partir de master grâce à git releng -s NEXT la version du paquet est changée en NEXT-releng.
  • on prépare un release candidate avec git releng -r
  • on prepare la version finale avec git releng -f, ce qui merge la branche de préparation dans release en ajustant la version, puis merge release – et tous les patches qu'elle pourrait contenir – dans `master.

Vos remarques et suggestions sont naturellement bienvenues!

Le paquet utilise BSD Make (bmake) et BSD Owl scripts il montre donc comment utiliser cet outil pour distribuer et préparer des scripts shell complexes. Le code shell est aussi intéressant à étudier pour ceux qui veulent étudier la programmation en shell.

N'oubliez pas de faire une sauvegarde de votre dépôt git avant d'essayer Anvil!

  • # Un amoureux du Bourne Shell

    Posté par  (site web personnel) . Évalué à 5.

    Tout d'abord, merci de présenter/partager ton projet.

    Voilà, maintenant je peux troller l'esprit tranquille :)

    Le paquet utilise BSD Make (bmake) et BSD Owl scripts il montre donc comment utiliser cet outil pour distribuer et préparer des scripts shell complexes. Le code shell est aussi intéressant à étudier pour ceux qui veulent étudier la programmation en shell.

    Pourquoi s'infliger le Bourne Shell alors qu'il existe pléthore de langages plus adéquates pour des projets de scripts « complexes » (Python, Ruby, Lua, name_your_favorite_langage,…) ? C'est le syndrome de Stockholm ?

    Je trolle un peu vite car il existe un avantage indéniable : l'interpréteur est disponible sur la plupart des Linux/BSD/Unix based OS d'aujourd'hui. Mais quand je vois le niveau de soin apporté à ce projet (oui je dis que d'habitude les projets Shell c'est crade…), je me demande : est-ce la seule raison ?

    Autre question, il y a deux licences dans ton source et tu ne mentionnes nulle-part la licence principale. C'est CeCILL-B ?

    • [^] # Re: Un amoureux du Bourne Shell

      Posté par  (site web personnel) . Évalué à 10.

      Pourquoi s'infliger le Bourne Shell alors qu'il existe pléthore de langages plus adéquates pour des projets de scripts « complexes » (Python, Ruby, Lua, name_your_favorite_langage,…) ? C'est le syndrome de Stockholm ?

      Ce n'est pas du tout le syndrome de Stockholm! Dans mon utilisation quotidienne des systèmes Unix, le shell est mon outil de travail. Ainsi, lorsque j'ai accompli une tâche en saisissant des commandes dans une session shell il est enfantin de transformer cette suite de commandes en procédure shell: il suffit de la recopier dans un fichier! On ne peut pas faire plus simple.

      De plus, le shell a aussi l'avantage qu'il est la lingua franca d'Unix, sidonc je veux utiliser git dans une procédure shell je n'ai pas besoin de recourir à des techniques d'envoûtement vaudou pour écrire des bindings bizarre pour faire dialoguer git avec mon langage préf́éré.

      Si j'utilise le shell pour décrire mes programmes, je peux aussi utiliser le langage de mon choix pour écrire mes sous-routines. Un petit programme C? Du OCaml, tout le monde peut se parler gr̀àce au shell!

      Mais quand je vois le niveau de soin apporté à ce projet (oui je dis que d'habitude les projets Shell c'est crade…)

      Merci, je suis content que ça se voie! :) Maintenant, lorsque tu verras des scripts shell tout crades tu pourras râler en montrant des exemples concrêts de code bien organisé!

      • [^] # Re: Un amoureux du Bourne Shell

        Posté par  (site web personnel) . Évalué à 5.

        Bon je suis content d'avoir posé la question parce qu'effectivement il y a des vrais arguments :)

        Je vais peut être reconsidérer le shell (j'ai vu que tu avais fait un article sur les bonnes pratiques de ce langage).

        Sinon… pour la licence ?

    • [^] # Re: Un amoureux du Bourne Shell

      Posté par  (site web personnel) . Évalué à 3. Dernière modification le 23 mars 2015 à 13:56.

      Tout d'abord, merci de présenter/partager ton projet.

      Et en plus maintenant il y a un paquet Debian (non officiel) qu'on peut télécharger sur la page Releases du projet.

      https://github.com/michipili/anvil/releases/tag/v0.3.0

  • # Avantage par rapport à Latexmk ?

    Posté par  . Évalué à 2. Dernière modification le 18 mars 2015 à 15:57.

    C'était pour un private joke, ne me moinssez pas trop.

  • # pourquoi?

    Posté par  . Évalué à 2.

    Pour les 3 premiers points je ne vois pas l’intérêt de ré-écrire l'histoire.

    • [^] # Re: pourquoi?

      Posté par  (site web personnel) . Évalué à 3.

      C'est utile quand on importe ou convertit un projet par exemple. J'ai écrit ces filtres lorsque j'ai du convertir des projets CVS et SVN en git, et j'ai profité de l'occasion pour nettoyer les fichiers. Lorsqu'on libère un projet fermé, le filtre sed permet de nettoyer le code, par exemple pour éliminer ou corriger certaines parties.

      Pour un rep en production, cela effectivement peu d'intérêt.

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.