Ceci est dû à une dépendance manquante et peut facilement se corriger à la main. Pour cela, installez le paquet ConsoleKit avec la commande suivante:

# yum install ConsoleKit

Et le problème sera réglé!

Comme j’utilise un système de contrôle des versions au quotidien (Bazaar, si vous ne connaissez pas, allez donc jeter un oeil), j’ai vite vu l’intérêt de la chose. Malheureusement, je n’ai pas trouvé d’équivalent de __git_ps1 pour Bazaar, j’ai donc écrit ma propre fonction Bash. Elle n’est pas aussi généraliste, mais rend bien service tout de même.

Voici le bout de code pour la fonction elle-même:

bzr_info() {
    status=`bzr status 2> /dev/null`
    revno=`bzr revno 2> /dev/null`
    parent=""
    if [ "$1" == "showparent" ]
    then
        parent=`bzr info | awk '/parent/ {print $3}'`
    fi
    if [ "$revno" != "" ]
    then
        echo -n "("
 
        if [ "$status" != "" ]
        then
            echo -n "*"
        fi
 
        if [ "$parent" != "" ]
        then
            echo -n "$parent:"
        else
            echo -n "bzr:"
        fi
 
        echo -n $revno
        echo -n ")"
    fi
}

Pour s’en servir, il suffit d’ajouter ce morceau de code dans votre prompt: \$(bzr_info), comme ceci:

PS1="[\u@\h \w\$(bzr_info) \$]"

Ce qui affichera ce genre de prompts:

[etenil@cray1 ~/Projects/test(bzr:121) $]
[etenil@cray1 ~/Projects/modified(*bzr:18) $]

Notez que si la branche a subi une modification non commitée, une étoile apparaît devant bzr. Vous pouvez aussi afficher la branche d’origine en passant l’argument showparent, comme ceci:

PS1="[\u@\h \w\$(bzr_info showparent) \$]"

Et qui affichera ce genre de lignes:

[etenil@cray1 ~/Projects/test(http://bzr.ath.cx/test/trunk:121) $]
[etenil@cray1 ~/Projects/test(*http://bzr.ath.cx/test/trunk:121) $]

Néanmoins, afficher l’origine est un peu plus lent et peut prendre beaucoup de place sur le prompt. A vous de voir!

Je vous passe le pourquoi du comment d’un tel système, n’étant pas designer pour un sou ; il suffira de dire que le CSS pré-défini rend le prototypage et la création de designs vite faits beaucoup plus rapide.

Le concept est simple. Il repose sur l’utilisation d’une grille en 960px à 12 ou 16 colonnes. Les éléments du site seront alors alignés dans cette grille pour un rendu du meilleur effet.

Le projet propose un package avec une suite de classes CSS pour faciliter la mise en oeuvre, et des templates pour Gimp et d’autres logiciels moins libres pour aider les designers purs et durs.

Au niveau du template CSS, il est assez simple de s’en servir. On définira un conteneur dans la page (ou plusieurs) avec comme classe container_12 (pour un 12 colonnes) ou container_16 et les éléments à l’intérieur seront quant à eux de classe grid_1, grid_2 ou grid_n, où n est la largeur désirée (en colonnes bien sûr).

(defun php-make-accessors (variable-name)
  "Insert a couple of accessors for the given member variable."
  (interactive "MVariable name (without $_): ")
  (let ((beg (point)))
    (insert (format (concat "public function set%s($value)\n"
                "{\n$this->_%s = $value;\n"
                "return $this;\n}\n\n")
            (capitalize variable-name) variable-name))
    (insert (format (concat "public function get%s()\n"
                "{\nreturn $this->_%s;\n}\n\n")
            (capitalize variable-name) variable-name))
    (indent-region beg (point))))

Il y a quelques limitations, notamment le fait que les propriétés doivent s’appeler $_xxx. Pour l’utiliser, copiez la dans votre ~/.emacs puis invoquez la fonction dans le corps de votre classe à l’aide de M-x php-make-accessors.

Voici une autre fonction qui emploie la première afin de générer une série d’accesseurs:

(defun php-make-accessors-list (vars)
  "Inserts accessors for each variables provided. Variables must be a
comma-separated string, e.g. \"a,b,c\"."
  (interactive "MVariables list (comma-separated, without $_): ")
  (let ((variables (split-string vars "," t)))
    (mapcar 'php-make-accessors variables)))

Pour employer celle-ci, faites M-x php-make-accessors-list, puis entrez les noms des variables pour lesquelles vous souhaitez générer des accesseurs, comme ceci: a,b,c pour accéder à $_a, $_b et $_c.

Créez ou éditez le fichier ~/.fonts.conf et insérez le code suivant:

<match target="font" >
 <edit name="embeddedbitmap" mode="assign">
  <bool>false</bool>
 </edit>
</match>

Et le rendu sera alors beaucoup moins agressif.

Edit

À la demande générale, voici deux screenshots de la bidouille:

Avant:

Après:

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

• Télécharger Anvil
• Accéder au code source

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.

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.

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.

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.