Mercurial est un système distribué de gestion de sources écrit en Python. Il permet à des développeurs de travailler avec leur code et de le versionner comme avec Subversion, mais sans avoir à dépendre d'un serveur centralisé: chaque modification est conservée localement, et le développeur peut à tout moment se synchroniser avec un autre repository, qu'il soit sur un serveur ou sur un autre poste de développement.

Un repository Mercurial est accessible entres autres en SSH, et peut être recopié localement pour être modifié (commande clone), puis mis à jour avec la commande push. L'utilisation de Mercurial est très similaire à celle de Subversion:

dabox:~ tarek$ hg
Mercurial Distributed SCM

basic commands (use "hg help" for the full list or option "-v" for details):

 add        add the specified files on the next commit
 annotate   show changeset information per file line
 clone      make a copy of an existing repository
 commit     commit the specified files or all outstanding changes
 diff       diff repository (or selected files)
 export     dump the header and diffs for one or more changesets
 init       create a new repository in the given directory
 log        show revision history of entire repository or files
 parents    show the parents of the working dir or revision
 pull       pull changes from the specified source
 push       push changes to the specified destination
 remove     remove the specified files on the next commit
 revert     revert files or dirs to their states as of some revision
 serve      export the repository via HTTP
 status     show changed files in the working directory
 update     update or merge working directory

Mettre en place un projet basé sur Mercurial consiste donc à mettre à disposition des développeurs un repository via un utilisateur SSH. Cette mise en place est expliquée sur cette page : http://www.selenic.com/mercurial/wiki/index.cgi/MultipleCommitters.

Mercurial propose, comme Subversion un système de hook pour effectuer des opérations lorsqu'un développeur "push" des modifications sur le serveur désigné comme "central". Un script pour envoyer des mails à chaque push est fourni sur le site, mais n'est pas très souple (script shell basic).

Voici un script Python qui offre un peu plus de souplesse:

#!/usr/bin/python
import sys
import os
import smtplib
from email.MIMEText import MIMEText
from ConfigParser import ConfigParser
from email.Utils import formatdate

conffile = os.path.join(os.path.dirname(__file__), 'commithook.conf')
config = ConfigParser()
config.read(conffile)

def command(cmd):
    return os.popen(cmd, 'r').read()

def send_mail(log, email, subject):
    msg = MIMEText(log, 'plain', 'UTF-8')
    sender = config.get('configuration', 'sender')
    prefix = config.get('configuration', 'prefix')
    msg['From'] = sender
    msg['To'] = email
    msg['Date'] = formatdate(localtime=True)
    msg['Subject'] = '%s %s' % (prefix, subject)
    server = smtplib.SMTP('localhost')
    try:
        server.sendmail(sender, [email], msg.as_string())
    finally:
        server.quit()

if __name__ == '__main__':
    hg_node = os.getenv('HG_NODE')
    subject = command('hg log -r %s | grep "^summary:" | cut -b 14-' % hg_node)
    emails = config.get('configuration', 'emails').split(',')
    for email in emails:
        log = command('hg log -vpr %s' % hg_node)
        send_mail(log, email, subject)

Il est associé à un fichier de configuration qui permet d'indiquer:

• le nom de l'expéditeur
• le préfix des mails
• la liste des emails

exemple de fichier:

[configuration]
sender=tarek_at_ziade.org
prefix=[commit]
emails=bob_at_gmail.com,tarek_at_ziade.org

Ces deux fichiers sont placés dans le répertoire .hg du repository du serveur, et indiqués dans le fichier hgrc de ce même répertoire:

[hooks]
incoming = commithook

Mercurial, pour conclure, est probablement l'un des systèmes de gestion de source les plus souples pour des projets personnels : le repository local peut être à tout moment cloné sur une autre machine, ce qui offre énormément de facilité pour partager son travail versionné, ou mettre en place un système de sauvegarde passif basé sur des push réguliers vers un serveur.

Il est probablement équivalent à Bazaar, que je n'ai pas encore testé.

Je suis tombé sur ce billet à propos d'OpenID via digg, un système que je ne connaissais pas et qui a un peu plus de 6 mois d'existence. OpenID est un système décentralisé de login développé par LiveJournal. Le principe est simple: le login sur un site est effectué par un appel à un webservice sur un site tiers en charge d'authentifier l'utilisateur.

Ce concept n'est pas nouveau (Passeport Windows,  Passeport Google..) mais ce qui est vraiment intéressant est que le login de l'OpenID est une url, correspondante au site qui sera appelé. En d'autres termes, il est possible de mettre en place son propre système d'identification pour conserver ses mots de passe au frais. Par exemple, si l'OpenID est tarek.ziade.org, il suffit d'implémenter à cet addresse un service OpenID conforme aux spécifications.

Pour des sites comme l'afpy, ou comme ce blog, proposer ce mécanisme d'authentification légère a un grand interêt pour les visiteurs qui souhaitent poster un commentaire, ou dans un forum. (une bibliothèque Python est disponible, et une implémentation Plone aussi apparament)

Reste à voir si ce standard va prendre, pour l'instant c'est un peu calme...

Je lisais le billet de David hier, sur ses essais avec un MacBook. Pour ma part ca fait maintenant deux mois que je suis passé à cette machine, et je suis aussi tout simplement conquis par sa qualité, son faible encombrement et sa maniabilité. Rapport qualité-prix imbattable. Et cette dalle de 13 wide est tellement lumineuse qu'elle vaut largement les 14 ou 15 wide de la plupart des PC.

En terme de système, Mac OS X est à mon sens le meilleur système d'exploitation actuel, et je l'ai pris en main sans le connaitre en quelques jours. Voici la liste des logiciels que j'ai installé pour mettre en place un laptop de développement et retrouver tout ce que j'avais sous Ubuntu:

• iTerm, pour remplacer le terminal de base et avoir un système d'onglets
• vim, qui est devenu mon éditeur de prédilection depuis
• adium, pour jabber et msn
• xChat, pour l'irc
• Firefox et Thunderbird
• TeXShop, pour l'édition LaTeX
• VLC, pour la visualisation des vidéos
• X11, et du coup: Ooo et Gimp
• Google Notifier
• MenuMeters : et oui, l'engin est tellement silencieux, qu'il est bon de savoir quand il travaille
• Fink et DarwinPort, pour installer tous les outils de dev. Par contre ca démultiplie les combinaisons, les PATHs etc.. je m'y perd un peu..
  

Et vous, quels sont les logiciels dont vous ne pouvez pas vous passer sous Mac ?

Au niveau du terminal, il a fallu le configurer pour que les touches home/end, del, etc, fonctionnent, et définir les locales.

• dans HOME/.profile, ajout de export LANG="fr_FR.UTF-8"
• et enfin voici mon HOME/.inputrc:

# inputrc - config file for libreadline
# Save as .inputrc (note the leading dot) in your $HOME directory
# See readline man page for more information.

set meta-flag on

# activate 8 bit characters
set input-meta on
set output-meta on
set convert-meta off

# suppress bell ringing
set bell-style none

# case insensitive TAB-completion
set completion-ignore-case on

# enable Delete/Home/end key in xterm and iTerm
"\e[3~": delete-char 
"\e[1~": beginning-of-line
"\e[4~": end-of-line

Les points négatifs de OS X sont inhérents au modèle commercial:

• impossible de regarder une vidéo en plein écran avec QuickTime: il faut acheter la version pro (!!)

• Le logiciel iWorks, pour faire des slides, est payant, les nagscreens n'oublient pas de le rappeler
• Avant l'installation de Ooo, le pack office m'a bien fatigué avec ses nagscreens aussi

Ca reste minime, mais c'est dommage pour les slides pilotables avec la télécommande, il faut que j'essaye avec Ooo...

En conclusion, je trouve qu'Ubuntu, que j'ai utilisé depuis quasiment ses débuts, n'est pas si loin que ça de Mac OS X en terme d'ergonomie et de qualité, et sera certainement au même
niveau d'ici quelques années. De plus, la supériorité d'une solution machine/os issue du même constructeur est de plus en plus relative: les laptops sont maintenant quasiment tous équivalents en terme de composants.

Quel malheur. PyCon 07 est en même temps que le FOSDEM cette année. Il en était de même cet été pour Europython et les RMLL. Le choix va être difficile, surtout que l'Afpy organise cet année une dev room entièrement consacrée à Python (yehaaa). Pour ma part le choix est fait car j'anime un tutorial à PyCon.

Les présentations

Pycon, c'est plus de 60 talks sur Python cet année :'). Voici celles que j'aimerais voir le plus:

• twill, scotch and figleaf (Titus Brown): outils pour les tests fonctionnels web
• the state of Python advocacy (Jeff Rush): par le responsable PSF de la promotion de Python
• testing tool panel (Grig Gheorghiu): panorama de tous les outils de tests pour Python
• the absolute minimum an open source developer must know about intellectual property (Van Lindberg): tout est dans le titre
• Distributing your project with Python eggs (Stephen Pascoe) : l'art du packaging
• Web framework panel (Titus Brown et al): "confrontation" des core developers des outils web. Toujours intéressant mais très dur à bien ficeler (ie le même panel à Europython qui était un peu désorganisé) On verra..
  
• Packaging Python apps for Linux Distributions (Monty Taylor) : beaucoup de choses à apprendre, et par quelqu'un qui sait de quoi il parle
• SQLAlchemy (Mark Ramm-Christensen): il va falloir y arriver tôt
• Interactive Parallel and Distributed Computing with IPython (Brian Granger) : wOOt
• Easy creation of interactive tutorials (Andre Roberge) : demo de Crunchy Python. Ca m'interesse au plus haut point car c'est proche de la documentation agile
• Python and VIM (Sean Reifshneider) : adieu pydev ;)
• Unit testing with mocxk objects using PyMock (Jeff Younker) : j'en ai parlé il y a quelques tickets. A voir/
• Software development with Trac (Matthew Good):  La partie plugins pour le developpement de QA tools et les liaisons avec buildbot.

Projet de reportage Python

Après le tutoriel je vais arpenter les conférences pour en voir un maximum. Il y aura certainement beaucoup de bloggeurs et filmeurs à Pycon mais probablement pas énormément de francophone. Je lance ici une proposition : si vous êtes passionné de Python et possesseur d'une petite caméra numérique, et prêt à me prêter ce matériel, je propose de faire des comptes rendus par blog et vidéos chaque jour passé à PyCon.