ludoka.net

Aller au contenu | Aller au menu | Aller à la recherche

Et pis ton organisation alors ¿

Dernièrement, je me suis acharné à empaqueter anoX pour Debian/Ubuntu, ce qui m'a amené à créer un installateur Python, à penser au support d'autres langues, à me demander quels fichiers d'information je devais fournir avec mes sources. Bref : Comment organiser les fichiers sources d'un projet libre ?

Mon idée est que quelque soit le projet, sa nature et ses langages de développement, je puisse adopter une organisation analogue qui me permettent de me repérer facilement tout en étant pratique et transparent pour un intervenant extérieur (créateur de paquet, contributeur, curieux, etc).

Je ne suis pas le seul à m'être posé ce genre de question : cet article de Jean-Paul Calderone[1] apporte quelques conseils sur l'organisation d'un projet Python.

Ma solution, qui diffère de celle de Jean-Paul Calderone :

  • Un répertoire data contenant toutes les données qui ne sont pas du code source (documentation, traduction, image, configuration, …) ;
  • Un répertoire src contenant le code source et les fichiers intermédiaires créés lors de la compilation ;
  • Un répertoire lib contenant les bibliothèques après compilation ;
  • La racine du projet ne contenant que les fichiers utiles à un utilisateur tels que un ou plusieurs exécutables (sans extension), un installateur (Makefile et/ou setup.py), ainsi que quelques classiques comme une licence (COPYING), un fichier lisez-moi (README), et tout ce qui semblera utile (attention toutefois, le moins sera le mieux).

Évidement un projet en python a quelques spécificités :

  1. Les exécutables à la racine ne doivent toujours pas avoir d'extension « .py » ;
  2. Les répertoires lib et src ne forment qu'un seul répertoire nommé :
    • du nom du projet pour une bibliothèque (par exemple mutagen),
    • du nom du projet précédé de lib pour une application (par exemple libquodlibet pour quodlibet).

Du point de vue du développement, le premier avantage est qu'il n'y a pas besoin de réorganiser les fichiers du projet au fil de son développement. Pour une application en python on commencera par créer un exécutable (par exemple anox, sans extension), puis on ajoutera plus tard une bibliothèque si le besoin s'en fait sentir (dans notre exemple, ce sera libanox) qui contiendra tous les modules et packages nécessaires.

De plus, l'installateur python est également facile à développer, puisqu'il n'y a pas besoin d'user de magie pour installer les scripts sans extension (anox dans notre exemple). Les sources et les données sont également clairement séparées, ce qui facilite l'empaquetage lorsque l'on veut créer un paquet de données à part (par exemple pour les jeux).

Mais surtout, une telle organisation est claire d'un point de vue extérieur, la racine du projet ne contient que ce qui est utile à l'utilisateur. C'est important car c'est la première chose que constate un utilisateur qui explore le projet en vue de le tester, l'utiliser ou y contribuer. Ainsi une application est également facilement exécutable après compilation et avant installation manuelle.

Notes

[1] Jean-Paul Calderone est un des auteurs de Twisted.

Un peu de style, que diable !

Ce soir, alors que j'écrivais un nouveau long billet que je vais bientôt publier, je me suis rendu compte d'une petite imperfection graphique de dotclear lorsqu'on est amené à utiliser beaucoup d'images flottantes à gauche... Pour éviter un "effet d'escalier", j'ai dû modifier légèrement deux fichiers CSS :

  • /themes/style.css à la ligne 212, où j'ai rajouté :
h1, h2, h3, h4, h5, h6 {
	clear: left;
}
  • /admin/style/default.css aux lignes 26 à 29, que j'ai remplacées par :
h1, h2, h3, h4, h5, h6, p {
	margin-top : 0;
	margin-bottom: 0.6em;
	clear: left;
}

Après ça, le résultat est beaucoup plus propre :D !! Bonne continuation ;) !

Patchs pour l'excellent Listen !

Ces deux derniers jours, j'ai travaillé à corriger deux "bugs" agaçants de l'excellent lecteur audio Listen. Bien que je ne connaisse rien à python, j'ai réussi, grâce au talentueux Eclipse, à débusquer les quelques lignes de code fautives...

Je vais maintenant partager avec vous, chers lecteurs, les fruits de mon travail. Avant toute chose, il faut savoir que j'utilise la beta 1 de Listen 0.5. Attention : les manipulations que j'indique ci-dessous peuvent être risquées pour un néophyte !

Bug sur le triage des chansons

Je souhaite tirer mes chansons d'abord selon leurs dates, puis par album, puis par numéro de piste, etc. Ce qui me permet :

  • d'avoir mes chansons de Matrix dans le bon ordre, bien que chaque piste aie un artiste différent, et
  • de classer mes albums de Star Wars dans l'ordre chronologique, qui n'est pas le même que l'ordre alphabétique.

J'ai donc brutalement patché le fichier /usr/lib/listen/song.py (ligne 319) sous ma ubuntu. J'ai remplacé la fonction def __sort_key(self) par :

    def __sort_key(self):   
        return(
                self.get_sortable("date"),
                self.get_sortable("album"),
                self.get_sortable("#track"),
                self.get_sortable("artist"),
                self.get_sortable("title"),
                self.get_sortable("#bitrate"),
                self.get_sortable("uri")
                )    
    sort_key = property(__sort_key)

J'ai également patché le fichier /usr/lib/listen/widget/song_view.py (ligne 190). J'ai remplacé la fonction def get_sort_by(self)) par :

    def get_sort_by(self):
        for header in self.get_columns():
            if header.get_sort_indicator():
                return (header.tag,
                        header.get_sort_order() == gtk.SORT_DESCENDING)
        else: return "date", None

Bug sur les couvertures d'album

Je ne souhaite sélectionner mes couvertures d'album que sur le critère du nom de l'album, sans considérer l'artiste. Cela part du principe que deux artistes ne peuvent avoir un album du même nom.

Ainsi j'ai brutalement patché le fichier /usr/lib/listen/song.py (ligne 640) sous ma ubuntu. J'ai remplacé la fonction def get_cover_search_str(self) par :

    def get_cover_search_str(self):
        art = ""
        #if not self.get_type() in sType.podcast and self.get_str("artist")!="":
        #    art=self.get_str("artist")+"+"
        if self.get_str("album")!="":
            art+=self.get_str("album")

        art = art.replace(os.sep,"")
        art = utils.filter_info_song(art).encode('utf-8')
        return art

Et après ?

L'auteur ne partageant pas le même point de vue que moi, il ne corrigera probablement pas ce que je considère comme des "bugs". En effet, il estime que deux artistes peuvent avoir deux albums avec un même nom (et pourquoi pas ?). De plus je ne crois pas qu'une majorité d'utilisateurs souhaitera voir les chansons triées principalement sur un critère de date. Donc je continuerais probablement à patcher les versions successives de Listen pour le customiser à ma sauce.

RSS+

Je suis étonné de voir à quel point mon plugin RSS+ pour dotclear 1.x est demandé. Ça fait plaisir :D !

Toutefois, même si je le remets en ligne, il ne sera plus maintenu.