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 :
- Les exécutables à la racine ne doivent toujours pas avoir d'extension « .py » ;
- 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.
