Tag Archives: planet-libre

Anvil

Posted on by
2

une forgeSi je n’ai pas été actif ces derniers temps, ce n’est pas par fainéantise (encore que…), mais parce que j’ai été fort occupé par mon dernier projet.

Vous connaissez sûrement GitHub ou Bitbucket, forges non-libres « sociales » qui facilitent l’emploi de git et mercurial, respectivement. Et de ce fait promeuvent donc ces deux outils.

Bazaar, qui est mon gestionnaire de versions favori, n’a lui que Launchpad comme forge dédiée et un tant soi peu « sociale ». Mais Launchpad n’a rien d’hype et il n’est pas vraiment simple à utiliser non plus. Du coup, je me suis dit qu’il fallait que je fasse le mien pour combler ce manque.

Je vous annonce donc la sortie d’Anvil 0.01 (enclume en anglais). Son but est de proposer un environnement collaboratif simple et une interface attrayante à Bazaar. Il est écrit en Python avec le framework libre web.py et la base de données MySQL. Anvil est disponible sous GPLv3.

Fonctionnalités

Accès au code

Point important pour une forge, Anvil propose un accès en HTTP pour les pull (accès public), et un accès via SSH pour les opérations de push.

Les dépôts gérés par la forge sont dans une arborescence du dossier de l’utilisateur bzr, lequel est dédié au logiciel. La partie SSH s’appuie quant à elle sur le fichier authorized_keys, qui permet de lancer un greffon pour Bazaar lors des connexions entrantes qui vérifie les droits d’accès et ré-écrit les chemins dynamiquement.

Messagerie interne

Anvil se veut social, même s’il n’a pas beaucoup de fonctionalités en ce sens pour l’instant. Il est toutefois déjà possible de contacter d’autres utilisateurs directement sur le logiciel plutôt que par email.

Le système de messagerie interne n’est pour le moment pas géré en AJAX et n’est donc mis à jour que lorsque la page est rafraichie. Ce système sera amené à évoluer dans les prochaines version pour plus d’utilité.

Branches Bazaar

Envoyer une branche sur Anvil est très simple puisqu’il suffit d’en pousser une qui n’existe pas encore. Bazaar crée alors dynamiquement la branche. Anvil apporte toutefois une possibilité que n’offre pas Bazaar directement, à savoir la suppression d’une branche (il suffit en fait de supprimer le dossier de la branche).

L’interface web permet de naviguer dans l’arborescence de la branche et de voir les fichiers avec coloration syntaxique.

Gestion de projet

Outre ses branches personnelles, les projets ont eux aussi leurs propres branches. L’intérêt réside dans le fait qu’on puisse y ajouter d’autres utilisateurs qui ont alors aussi le droit de modifier les branches du projet.

Gestion de bugs

Le système de gestion d’incidents d’Anvil se veut simpliste et ouvert. On peut par exemple y reporter des bugs sans pour autant être enregistré sur la forge.

Gestion documentaire

Anvil permet une gestion documentaire très simple et permet d’écrire des documents en Markdown attachés au projet. Il ne gère pour le moment pas les versions des documents.

Ubiquité de Markdown

Markdown est un format pratique, et Anvil l’utilise un peu partout, aussi bien dans les profils utilisateurs que les descriptions de projet ou la documentation. Le but est de permettre aux développeurs d’offrir facilement un contenu riche.

État des lieux

Cette version est la première à être utilisable, mais présente bien des défauts.

Le code est plutôt mal organisé, manque de commentaires et les bugs sont probablement légion. L’interface est en Anglais et pour le moment rien n’a été prévu pour les traductions.

Installer Anvil est assez simple mais réclame tout de même une petite expérience d’administration système. J’ai écrit un readme qui décrit l’installation pas à pas de la forge avec Apache2 et mod_fcgid.

Futur

Les buts pour la version 0.02 n’ont pas encore été définis formellement, mais l’accent sera mis sur la correction des bugs et le nettoyage du code, ainsi que l’amélioration du thème par défaut.

Liens

Hacker bazaar

Posted on by
2

Salut à tous.

Je n’ai pas été actif sur ce blog ces derniers jours (grippe, tout ça), mais je n’ai pas pour autant été fainéant. J’ai en effet quelques tutos dans les cartons, et en particulier concernant Bazaar (le dvcs qui est mieux que git).

J’ai dernièrement dû hacker Bazaar pour un autre projet que j’annoncerai bientôt. Ça m’a donc permis de me familiariser avec les tripes de la bête et en particulier bzrlib. Car si bazaar est un bon dvcs, sa force reste le fait qu’on peut programmatiquement tout faire grâce à sa bibliothèque.

Voici donc un petit tuto pour lister les fichiers d’une branche de bazaar (et même d’une branche d’un repo sans arbre):

from bzrlib.branch import Branch
b = Branch.open("/emplacement/de/ma/branche/")
t = b.basis_tree()
b.lock_read()
files = t.iter_entries_by_dir()
for f in files:
    print f[0]
b.unlock()

Ce qui pourra donner ceci:

index.php
movicon
run-tests.php
apps/movicon
apps/tests
apps/movicon/app.ini
apps/movicon/controllers
...

Chaque élément de l’itérateur renvoyé par iter_entries_by_dir() est un tuple dans la forme (fichier, objet). L’objet en second membre contient les informations nécessaires pour connaitre la taille du fichier, son hash sha1, et sa référence unique pour pouvoir l’obtenir (ce qui nous intéresse davantage).

On peut donc obtenir un fichier directement et le manipuler à notre guise (le tout sans tree, c’est classe).

... # Voir plus haut
for f in files:
    if f[1].__class__ == bzrlib.inventory.InventoryFile:
        print t.get_file_text(f[1].file_id)
        break
b.unlock()

Ici on itère dans les fichiers encore, et on teste le type du second membre du tuple. On peut soit avoir le type CHKInventoryDirectory (pour un dossier) ou bien InventoryFile (pour un fichier). Lorsqu’il s’agit d’un fichier, on attrape son contenu et on l’affiche dans stdout. ensuite je break pour éviter de flooder la sortie (c’est juste un test).

Évidemment on peut faire une ribambelle d’autre choses avec bzrlib, mais autant commencer par les choses simples.

Pourquoi git me hérisse le poil

Posted on by
30

Voici un article trollesque en perpective. En fait j’aimerais bien, parce qu’au-delà de doper mes statistiques, ça voudrait dire que git est efficace et que je suis un menteur, donc que je n’ai jamais fait l’expérience que je vais vous relater.

Commençons par une petite définition. Programmer est une activité délicate qui demande beaucoup de concentration, et toute la partie logistique de la programmation, bien que passionnante, doit se faire aussi transparente que possible. Pousser son code quelque part ou ajouter le code de son voisin au sien doit être une étape simple, avec des commandes simples (si on doit regarder la page de man c’est foutu).

Vous n’êtes pas sans savoir que je me suis retrouvé impliqué dans le projet Movim, un réseau social libre basé sur XMPP, lequel utilisait git à l’époque. Il n’y avait qu’un seul dévelopeur, donc le workflow était très simple et n’importe quel VCS aurait fait l’affaire.

Suite à mon arrivée dans le projet, nous avons mit en place un workflow similaire à celui employé dans le noyau linux pour le projet, c’est à dire que chacun travaille sur une feature dans son coin et on merge dans le master (sorte de branche commune au projet) quand c’est mûr. Jusque là rien de compliqué.

Sauf que git ne l’entendait apparemment pas de cette oreille. Ainsi nous perdions environ une heure à chaque merge à essayer de comprendre pourquoi diable git ne voulait pas fusionner nos changements. C’est ainsi que lors d’un merge, les messages d’erreurs de l’outil étaient trop cryptiques pour moi, et donc comme d’habitude quand je suis dépassé, je demande de l’aide. Je me suis pointé sur le salon IRC de git, et quelques bonnes âmes expérimentées ont essayé de m’aider. Sans succès. Au final j’ai décidé de fusionner les deux codes à la main (enfin avec emacs et emerge) puis commiter, très sale mais au bout de 2h face à un mur, on n’est plus à ça près.

Après deux ou trois sorties de Movim à faire face à ce problème sans que la situation s’améliore (oui on pensait que c’était notre faute), nous avons finalement décidé d’arrêter les frais et de tenter le coup avec un autre VCS; n’importe lequel. On nous a chaudement conseillé Mercurial, et Bazaar un peu moins. Mais Mercurial ressemblait un peu à git et chat échaudé craint l’eau froide. Qui plus est j’avais déjà eu l’occasion d’utiliser Bazaar dans un workflow centralisé (comme subversion), et donc connaissais sa versatilité.

Nous avons donc décidé de faire la sortie suivante sur bazaar en synchronisant sur git (au cas où). Et nous avons été ébahi lorsque bazaar ne s’est pas une seule fois plaint, que les conflits étaient très explicitement indiqués et finalement nous sommes passés d’1h par merge à 5 minutes.

Depuis il m’arrive de voir des articles qui vantent les mérites de git contre d’autres, et c’est sûrement vrai qu’il est techniquement très efficace, voire supérieur, mais ce n’est pas un outil fait pour aider le programmeur.

Sommes-nous formattés par nos distributions?

Posted on by
8

Dans le dernier GNU World Order podcast, le podcasteur parle d’une chose que les distributions GNU/Linux ont réussi à nous imposer. Il s’agit des dossiers « standards » dans les dossiers utilisateur.

Effectivement, il y a quelques années, on se retrouvait avec un dossier HOME tout nu (pas de blague hein!). Puis tout doucement les différentes distributions on commencé à créer les dossiers des utilisateurs avec une structure de base (du genre Musique, Photos, Videos, Documents). Et je me suis aperçu que j’utilisais au départ une structure de dossiers à moi, puis je suis passé sur cette structure par défaut.

Mais en réalité cette structure par défaut n’a pas beaucoup de sens et ajoute en fait à la confusion dans mon dossier personnel. Par exemple je range naturellement tous mes fichiers audio dans Musique, hors beaucoup d’entre eux sont des podcasts ou des enregistrements de conférence. Encore pire pour Documents, qui contient indistinctivement des factures, ebooks et autres pages web sauvegardées.

Un cauchemard pour les back-ups. Donc ne vous laissez pas avoir par votre distro! Rangez vos fichiers dans un ordre logique.

Petite remarque sur EMACS24

Posted on by
Reply

Après vous avoir révélé les nouveautés de la version 24 d’EMACS, j’ai donc installé emacs-snapshot histoire d’en avoir un avant goût.

Je n’ai pas encore beaucoup testé la chose, mais je peux déjà dire qu’il est très très rapide. En effet EMACS23 prenait environ 4s ou 5s pour lire toute ma configuration et être utilisable, alors que le nouvel EMACS est prêt en 1s ou moins. Je ne sais pas comment ils ont fait, en tout cas j’en suis très satisfait :)

Si vous voulez aussi tester emacs-snapshot, vous pouvez le faire facilement sur debian, je pense qu’il y a un ppa aussi pour ubuntu, mais je vous laisse le chercher.