(En utilisant sudo si nécessaire.)

Mais si vous tapez python setup.py uninstall vous aurez cette erreur :

Ajouter un rôle uninstall à setup.py

Voici mon setup.py qui gère les rôles habituels :

• install
• sdist
• clean

Et qui y ajoute le rôle uninstall :

Il est aussi disponible dans le dépôt Bazaar sur Launchpad.net : http://bazaar.launchpad.net/~zedtux/tuxtremsplit/trunk/annotate/head%3A/setup.py

Comment ça marche ?

Étape 1 : Fixer les arguments

Pour pouvoir bien désinstaller votre projet, il faut savoir quels sont les fichiers que vous copiez à droite et à gauche.
Tout ça étant déjà défini dans la méthode setup(), il serait bête de tout re-définir encore une fois dans la désinstallation.
Et bonjour le maintien !

Pour régler ça, setup() peut prendre un argument –record puis un emplacement de fichier.
Ce fichier contiendra tous les fichiers copiés ! Donc les supprimer par la suite est un jeu d’enfant !

Donc le rôle install va commencer par appeler la méthode fix_args() qui ajoute si nécessaire l’argument –record puis ./uninstall.list.

Étape 2 : La version

Lorsque vous faites un python setupy.py install, le script va d’abord chercher à récupérer la version courante du projet. Il va donc tenter de lire un fichier VERSION, à la racine du projet. (Moi, je le génère avec un Makefile, et un rôle version). Cette version sera utilisée pour compléter la valeur du champ version de la méthode setup().

Cette étape me sert lorsque je fais un make builddeb.
Ce rôle a besoin que la version du fichier debian/changelog et celle du setup() de setuptools soient les mêmes.

Du coup, lorsque je fais une modification, j’utilise debchange pour maintenir le fichier debian/changelog.
Si je crée une nouvelle version avec debchange -v new.version.id, la commande crée une nouvelle entrée dans le fichier debian/changelog pour cette nouvelle version, et renomme automatiquement le dossier du projet avec cette version (obligatoire pour l’empaquetage).
Du coup, il faut que tous les acteurs dans l’installation et l’empaquetage soient au courant de cette version !

Étape 3 : L’installation

Là, le script travaille comme l’original : il lance la méthode setup() qui installe les fichiers.

Étape 4 : Exécution de commandes diverses

J’avais besoin, pour installer un nouveau MimeType avec mon application, de lancer quelques commandes (que j’ai laissées comme exemples).
Un tableau contenant les commandes et leurs arguments à exécuter est itéré afin d’appeler la méthode execcmd().

Avec ce fichier setup.py, mon programme TuXtremSplit s’installe entièrement, et se désinstalle proprement !

J’ai donc pondu cette petit ligne qui le fait tout simplement :

Ce système de tag pas toujours reconnu (même par les plus grands) peux s’avérer très pratique.

Une fois que j’ai eu vent de cette spécificité, j’ai immédiatement effectué un test sur mon serveur qui utilise PostFix + MySQL pour gérer les adresses virtuelles.

Malheureusement, la requête SQL en charge de vérifier l’existence du destinataire recopie les tags et donc retourne NULL.

Une petite recherche plus tard, et je découvre le sésame :

sudo postconf -e « recipient_delimiter = + »

Un restart de PostFix et roulez jeunesse ! Ça marche !

Si vous utilisez des features en Gherkin[en] (avec cucumber par exemple) pour faire du Behavior Driven Development, voici une petite macro écrite par mon collègue Greg (avec qui je bosse en pair)  qui va corriger les espaces manquants qui permettent à TextMate de découper votre fichier en sections rétractables !

La macro n’est basée que sur un seul cas pour le moment. Elle recherche les retours ligne doubles (entre deux scenarii) où ces fameux espaces sont manquant ou trop nombreux pour en mettre le bon nombre.

Mais nous allons essayer d’améliorer cela encore

Avant

Prenons l’exemple affiché sur le site de cucumber. Voici le résultat dans TextMate :

Vous pourrez remarquer sur cette capture que TextMate veut découper le fichier en sections rétractables (ligne 7 et 13), mais il ne retrouve pas la fin de la section, et c’est donc inutilisable.

Après

Maintenant, utilisons la macro de Greg avec ⌘ + ctrl + shift + F.

Et voici le résultat !

Voilà ! TextMate retrouve la fin des sections, et les affiche (ligne 12 et 18).

Maintenant vous pouvez utiliser ⌘ + 0 pour replier ou déplier toutes les sections et ainsi obtenir :

Dans une grande feature, ça devient vite intéressant pour éviter d’user votre molette et de chercher dans quel scénario vous travaillez !

Téléchargement

La macro est disponible dans mon dépôt Subversion à cette adresse : http://svn.zedroot.org/Guillaume%27s%20bundle.tmbundle/Macros/Format%20feature.tmMacro

Pour l’installer, il vous suffit de la mettre dans un nouveau bundle, ou un existant, ou simplement de faire un checkout de mon bundle dans ~/Library/Application\ Support/TextMate/Bundles/

Sur la machine du boulot :

Et chez moi :

Finalement, j’ai enfin pris le taureau par les cornes et étudié comment créer un dépôt PPA que Launchpad.net (créé par Canonical, la société à l’origine d’Ubuntu) met à disposition de ses membres.

Ça va me permettre de distribuer mes applications telles que TuXtremSplit très simplement, grâce à l’utilisation d’apt, et de add-apt-repository !

Point de départ

Disons que vous avez un compte Launchpad, activé, avec le code de conduite[en] signé, et une clé GPG importée dans Launchpad

Je prendrai mon programme TuXtremSplit pour l’exemple puisqu’il est divisé en 2 :

• Une librairie contenant le « moteur »
• Un client console pour utiliser cette bibliothèque

Donc il va falloir préparer la bibliothèque en premier, puis la console, sachant que cette console va donc dépendre de la bibliothèque.

C’est parti !

Bon, pour commencer, il faut donc les sources !

Ensuite, il va falloir créer un dossier de travail pour créer vos paquets, afin de l’envoyer vers un PPA.

Création du plan de travail, récupération des sources

Je vous propose donc de récupérer les sources dans un dossier developpements/ et de créer un dossier empaquetage/

Ensuite, placez vous dans le dossier developpements/ puis avec un VCS (Versioning Control System[Wikipedia]) tel que subversion récupérez les sources :

svn co http://svn.zedroot.org/TuXtremSplit::v2/trunk/ tuxtremsplit

Vous aurez un dossier tuxtremsplit/ qui contient :

console/

library/

modules/

…

Puis des fichiers dont un CMakeLists.txt qui est mon fichier de configuration pour CMake.

Préparation

Nous allons préparer la zone d’empaquetage.

Nous allons créer un dossier tuxtremsplit/ dans le dossier empaquetage/ puis nous allons, dans le dossier tuxtremsplit/, créer les dossiers console/ et library/ :

mkdir -p empaquetage/tuxtremsplit/console/

mkdir empaquetage/tuxtremsplit/library/

Donc nous allons séparer le code de la bibliothèque et celui de la console afin d’avoir deux paquets différents.

Maintenant il nous reste à placer le code dans chaque dossier, afin de pouvoir passer à la suite !

Pour ce faire, vous n’avez qu’à copier developpements/tuxtremsplit/library/ dans empaquetage/tuxtremsplit/library/

cp -R developpements/tuxtremsplit/library/ empaquetage/tuxtremsplit/library/

Rassurez vous, ce n’est pas une erreur de ma part d’avoir copié le dossier entier, car nous allons le renommer !

En effet, l’outil que nous allons utiliser bientôt a besoin d’être lancé dans un dossier nommé comme le sera le paquet, c’est-à-dire avec le nom du programme, un trait d’union, puis la version:

mv empaquetage/tuxtremsplit/library/library/ empaquetage/tuxtremsplit/library/libxtm-1.0.1.1

Donc libxtm pour la bibliothèque, puis 1.0.1 pour la version. Le dernier 1 de la fin représente la version du paquet. Vous aurez très certainement à recommencer vos envois… et vous allez comprend pourquoi à ce moment là !

Faisons pareil pour la console :

cp -R developpements/tuxtremsplit/console/ empaquetage/tuxtremsplit/console/

mv empaquetage/tuxtremsplit/console/console/ empaquetage/tuxtremsplit/console/tuxtremsplit-2.0.1.1

Ici pareil, le dossier console/ est renommé en tuxtremsplit pour le nom du programme, puis sa version 2.0.1, puis la version du paquet.

Nettoyage

Avant de passer à l’action, il reste à nettoyer les sources. En effet, Subversion crée des dossiers .svn/ qui n’ont rien à faire dans nos paquets !

find empaquetage/tuxtremsplit/ -name ‘.svn’ -type d -exec rm -rf {} \;

Créer le fichier source compressé

Créer un paquet debian veux bien dire empaqueter un code source téléchargé quelque part, pour le mettre dans un trentenaire de type debian.

Il faudra donc donner une archive de ces sources.

tar -czf empaquetage/tuxtremsplit/library/libxtm-1.0.1.1.tar.gz empaquetage/tuxtremsplit/library/libxtm-1.0.1.1/

tar -czf empaquetage/tuxtremsplit/console/tuxtremsplit-2.0.1.1.tar.gz empaquetage/tuxtremsplit/console/tuxtremsplit-2.0.1.1/

Identification

Nous allons finir la préparation de notre plan de travail par notre identification au prêt de Launchpad pour la création du paquet !

Il existe deux variables d’environnements qui contiennent votre nom/pseudo et votre email. Généralement, ont met ça dans le fichier ~/.bashrc comme ceci (remplacez pour vous) :

DEBEMAIL=adresse.email.de.votre.compte.launchpad@exemple.org
DEBFULLNAME=’Launchpad PPA for Nom Prénom’

dh_make

Les choses sérieuses commencent !

dh_make est une commande qui va vous créer un répertoire debian/ dans les sources ainsi qu’un tas de fichiers (dont une série que l’on supprimera), qui sont indispensables pour créer un paquet debian !

Commençons par installer dh_make !

sudo apt-get install dh-make

Maintenant ouvrez un terminal dans le répertoire empaquetage/tuxtremsplit/library/libxtm-1.0.1.1/ et lancez cette commande :

$ dh_make -l -f ../libxtm-1.0.1.1.tar.gz

Maintainer name : Launchpad PPA for Nom Prénom
Email-Address : adresse.email.de.votre.compte.launchpad@exemple.org
Date : Thu, 28 Aug 2010 20:29:00 +0200
Package Name : libxtm
Version : 1.0.1.1
License : blank
Using dpatch : no
Using quilt : no
Type of Package : Library
Hit <enter> to confirm:

Pressez « Entrée » pour valider. Maintenant le dossier debian/ est apparu, et contient un tas de fichiers.

Préparation des fichiers de paquet

Nettoyage

Pour commencer, il n’y a que quelques fichiers qui nous intéressent. Le reste, on le vire :

rm debian/*.ex; rm debian/*.EX

changelog

Le fichier changelog est très important et respecte aussi une syntaxe très stricte. (Nombre d’espaces import etc…). Pour nous faciliter la tâche, nous allons utiliser la commande dch qui permet d’éditer simplement ce fichier changelog.

Cette commande n’est pas encore installée, alors commençons par ça :

sudo apt-get install devscripts

Comme c’est la première création du paquet, et que dch ajoute au fichier changelog, et ne remplace pas l’existant, nous allons effacer le fichier changelog, et le re-créer :

rm debian/changelog

dch –create –package libxtm -v 1.0.1.1-1 « Initial release »

Pour en finir avec le fichier de log, il faut initialiser la release avec :

dch -r

Attention à bien sauvegarder ! Vous devez trouver le nom de la release d’Ubuntu dans le fichier de log.

Maintenant, quand vous voudrez ajouter une entrée au fichier, vous n’aurez qu’à faire :

dch -i « Le nouveau log à ajouter »

C’est tout !

control

Le fichier control est le fichier principal car il contient toutes les infos importantes sur le paquet comme les dépendances, la description, la version, etc. Ouvrez-le avec votre éditeur de fichier texte préféré et en route !

Commencons par le plus dur : Build-Depends. Ce champ contient donc les dépendances qui seront utilisées pour construire votre application.
Pour TuXtremSplit vous devez mettre :

Build-Depends: debhelper (>= 7), cmake, libmagic-dev, libglibmm-2.4-dev, libglademm-2.4-dev, libgtkmm-2.4-dev, libboost-regex-dev, libssl-dev

Je vous mets directement le fichier complet, ça sera plus simple :

copyright

Fichier important pour ne pas froisser un développeur !

Voici le mien :

libxtm.install

Ce fichier précise comment installer le fichier de bibliothèque. Vous devez donc y mettre :

usr/lib/lib*.so.*

Pour prendre en compte les fichiers lib*.so.* (donc libxtm.so.0 par exemple)

libxtm-dev.install

Comme le précédent, sauf qu’il contiendra les fichiers d’en-tête. Il faut y mettre :

usr/include/*

usr/lib/*.so

Construction du paquet

Maintenant nous sommes prêts pour créer notre paquet deb ! (Toujours dans le dossier empaquetage/tuxtremsplit/library/libxtm-1.0.1.1/)

debuild -S -sa

A la fin de cette étape, il vous sera demandé 2 fois de suite la passphrase de votre clé GPG pour signer les paquets (libxm et libxtm-dev).

Envoie au PPA

Voici la dernière étape ! Envoyer tout ça au PPA pour qu’il lance la construction et pour qu’il mette en ligne votre paquet !

Pour ce faire, il faut utiliser la commande dput.

Dans le dossier empaquetage/tuxtremsplit/library/ :

dput ppa:zedtux/tuxtremsplit libxtm_1.0.1.1-1_source.changes

Vous trouverez pour votre PPA la commande à exécuter dans l’interface de Launchpad.

Vous allez recevoir un email dans quelques instants, vous indiquant si votre demande est acceptée ou pas, et en vous expliquant pourquoi.

Il ne vous reste plus qu’a surveiller la construction et voir en cas de problèmes le pourquoi et le fixer !

Ce mois-ci au boulot, il y a eu quelques petits changements dans les méthodes de travail : L’intégration de plus de méthodes Agiles.

Les méthodes avant

Le Behavior Driven Development

Le Behavior Driven Development ou BDD, est la première méthode Agile que j’ai apprise.

Cette méthode Agile est basée sur le Test Driven Development ou TDD, qui, en résumé, consiste en l’écriture de tests avant celle du code, sauf qu’elle ajoute une couche supplémentaire aux tests.

Cette nouvelle couche est, elle, écrite dans la langue maternelle, normalement, ou une langue commune aux différents acteurs implémentant la nouvelle fonctionnalité. Le principe théorique est que tout le monde participe, c’est-à-dire le demandeur de la nouvelle fonctionnalité, le gestionnaire de projets, les développeurs, les testeurs, …
L’idée est que le demandeur de la nouvelle fonctionnalité et le gestionnaire de projet écrivent ensemble ce que l’on appelle une feature, contenant des scenarii décrivant la nouvelle fonctionnalité, qui eux-mêmes contiennent les différentes étapes (steps) que le demandeur de la nouvelle fonctionnalité effectue pour aboutir à sont besoin. (Quand je clique sur …  je dois voire un message …)

Une fois cette feature prête, il ne reste qu’à utiliser un programme prévu à cet effet, comme par exemple cucumber, ou encore lettuce, qui vont passer en vert les étapes valides, et en rouge les étapes ne fonctionnant pas. Du coup, votre mission sera de tout faire passer en vert. Donc comme pour le TDD, il faut écrire les étapes des scenarii avant de faire le code.

Cette méthode assure un niveau de qualité encore supérieur au TDD, et étant exécuté par le serveur d’intégration continue à chaque commit, vous saurez très vite si vous venez de régresser dans votre code !

Les méthodes après

La méthode kanban

La méthode kanban est ultra simple, mais ultra efficace surtout si elle est bien respectée !

Je ne vais pas donner d’explications, car cet article de ce blog le fait extrêmement bien (Merci et bravo à son auteur !)

Maintenant nous avons une vue claire de ce qui est à faire, ce qui se fait et par qui.
Nous voyons aussi où les demandes coincent…

Bref, une super méthode, même si elle n’est pas encore complètement mise en place…

Le pair programming

La programmation en binôme est quelque chose que j’attendais depuis un moment ! C’est le changement le plus important de ce mois-ci !

Un collègue de boulot a déménagé à côté de moi, et nous pratiquons cette méthode seulement depuis 2 semaines, mais le résultat et les bienfaits apparaissent déjà ! Nous travaillons donc sur le même ordinateur en collaboration. Cette méthode n’a (à mes yeux) que des avantages pour le moment :

• Concentration maximale : On passe moins de temps à glander, ou à s’auto-distraire et donc plus à coder. L’un l’autre ont se motive à bosser.
• Communication plus intense : Nous discutons de comment corriger/implémenter telle ou telle chose de la meilleur façon possible.
• Apprentissage : L’un apprend à l’autre et vice versa.

Conclusion

Tout n’est pas fait dans les règles de l’art, certes, mais ces changements sont assez motivants, même si au final, pour le moment, le boulot, lui, reste trop monotone.

Je viens d’être confronté au problème suivant:

• Je désire contribuer à un projet qui utilise un dépôt subversion en lecture seule.
• Mes modifications ne se font pas en 1 journée.
• Je ne doit pas perdre mes modifications.
• Je doit avoir le tout dernier code au fur et à mesure.

Comment faire sans pouvoir faire de commit ?

Un script bash qui se charge de tout !

Encore une fois, un bon développeur est un développeur mort feignant !

Voici donc un script bash que je vient décrire qui créer un patch des modifications courante du dépôt subversion, puis efface tout les changements afin de lancer un svn update pour avoir les derniers codes sources. Il ne reste plus qu’à patcher les sources avec le patch.

Comme c’est un peu pourris les plugins pour afficher du code … je vous ai mis ca sur mon dépôt SVN : http://svn.zedroot.org/ZedUtils/trunk/svn_stash

Voici un premier aperçu de la fenêtre dite d’action, qui affiche ce qui se passe.

Ici l’idée est que lorsque vous double-cliquerez sur un fichier .001.xtm (valide), TuXtremSplit se lancera automatiquement, affichant cette fenêtre.
J’ai trouvé bonne l’idée de la petite phrase détaillant le fichier contenu dans les fichiers XTM, sa taille etc…

Seule bémol pour le moment (je réfléchis à une solution), les fichiers auto-extractible généré par Xtremsplit sont reconnut comme application Windows à exécuter avec Wine. Cela dis, si le système d’identification des fichiers de freedesktop.org est assez complet, peut-être il sera possible de détecter l’entête d’un XTM, et du coup, l’associer à TuXtremSplit.
Autre problème: Pour une raison inconnu, le développeur d’Xtremsplit utilise UPX (Ultimate Packer for eXecutables) pour empaqueter le premier fichier .001.exe, du coup l’entête est offusqué… Donc à voire comment gérer cette drôle de situation.

Si vous avez des propositions, idées, suggestions, n’hésitez pas, je suis ouvert !

P.S: L’étoile ici est juste là temporairement, le temps d’essayer de trouver une icone plus adapté.

Vous devez vous dire « Encore une nouvelle version alors que la 2.x n’est pas fini ?? »

En effet, j’ai commencé la fin de semaine dernière la ré-écriture de TuXtremSplit[sur Launchpad], mon clone d’Xtremsplit !

Pourquoi une nouvelle version ?

Pour ceux qui ont suivi le fil de discussion du forum ubuntu-fr.org, ou qui me parle par messagerie instantané, vous savez que ce projet est un projet d’apprentissage pour moi.

C’est à dire que j’apprends les langages de programmation grâce à ce projet.
La version 1 était en C, la version 2 en C++ et maintenant la version 3 en Python.

Ce qui explique pourquoi le projet évolue aussi bizarrement.

Pourquoi Python ?

La première raison est que Python est très populaire sur ma distribution préféré: Ubuntu.
Plusieurs sessions sur IRC à suivre des présentations de Python et ton son petit monde, des tas d’applications en Python etc …

La second raison est que actuellement, au boulot, je bosse avec du Ruby, qui est un langage très ressemblant au Python.
(Cela dis, je préfère Ruby à Python.)

Ce qui est prévue au programme ?

Une fois tout le code écrit pour réaliser les deux taches principale du programme, qui sont joindre et couper des fichiers, je vais forcer l’accent sur l’intégration dans GNOME.

• J’ai très récemment lu le GNOME Human Interface Guidelines, que je vais essayer de suivre au maximum.
• J’imagine une intégration tel, qui vous permettent, en un double clique sur un fichier xxxxxxxxxxx.001.xtm de lancer le collage des fichiers.
• Je vais aussi reprendre là où j’en étais avec l’intégration dans Nautilus (Icône spécial pour le fichier 001.xtm)

Bref,  j’espère produire un outil peaufiné dans ses moindre détails !
En espérant aussi avoir du retour de votre part sur ce qui manquerai, serai à changer, etc …