J'ai mené plusieurs petits projets Python (modules, sites Django, application Qt, …).
Ayant pas mal appris au cours du temps, je me rends bien compte qu'ils comportent de gros défauts de mise en forme (packaging, tests, doc, …).
De plus, je me rends aussi compte qu'il y a pas mal de choses répétitives (surtout dans un projet Django).
Je me suis donc lancé dans un projet permettant de créer un template de projet Python qui soit suffisamment complet.
L'idée est de fournir un petit utilitaire en ligne de commande qui demande quelques infos de base (du genre : nom du projet, licence, url, …) et le type (interface Qt, interface ligne de commande, site Django, …), et qui s'en sert pour créer la structure de base. Le résultat obtenu ne permettra sûrement pas de faire tout ce qu'on veut par défaut, mais ce n'est pas trop grave.
Voici la structure que je veux obtenir pour le nouveau projet :
MonNomDeProjet/
+-- monmodule/
| +-- data/
| +-- submodule/
| | +-- __init__.py
| | +-- submain.py
| +-- __init__.py
| +-- main.py
+-- doc/
| +-- source/
| | +-- api/
| | +-- submodule/
| | | +-- submain.rst
| | +-- index.rst
| | +-- main.rst
| | +-- submodule.rst
| | +-- conf.py
| | +-- index.rst
| | +-- install.rst
| +-- build/
| +-- Makefile
| +-- make.bat
+-- tests/
| +-- __init__.py
| +-- runall.py
+-- README.txt
+-- setup.py
+-- CHANGELOG.txt
Le fichier monmodule/__init__.py exporte un certain nombre d'infos classiques (__author__, …) et un peu moins classiques (le nom du main à appeler par un script en ligne de commande, celui à appeler par l'application graphique, etc.
Accessoirement, le setup.py créé doit fournir un certain nombre d'utilitaires et de commandes :
- génération des « binaires » appelés directement par l'utilisateur (qui se contente en fait d'appeler le main).
- toutes les infos nécessaires pour une intégration minimale au bureau (fichier .desktop, associations de fichiers, …)
- lancement des tests
- vérification de la qualité de code
- génération du sous-dossier doc/source/api (pour lister les modules codés)
- création de la doc
- lister les dépendances
- génération des paquets .tar.gz, .deb, .rpm, mais aussi Windows et OS X
Comme je suis un gros flemmard, je veux coder le moins possible, naturellement :p
Donc :
- j'écris cette structure une fois, et je transforme le tout en templates jinja2
- qualité du code -> pylint
- génération de la doc -> sphinx
- liste des dépendances -> snake-food
- tests unitaires -> unitests ?
- génération des paquets -> py2app, py2exe, bdist_deb, bdist_rpm, …
Je pense que je ferai également un main basique, avec l'utilisation d'optargs et d'un fichier de configuration par utilisateur si on fait un utilitaire en ligne de commande, et une application Qt vide, mais propre.
J'ajouterai peut-être aussi une commande commit (qui fait un svn st pour voir s'il manque des fichiers, ajoute le message au changelog, et fait le svn ci) et une commande update (bon, ok, faudrait faire la même chose pour d'autres systèmes de versionning, mais plus tard).
Et si ça intéresse du monde, j'essaierai de le mettre sur GitHub :-) Même si en soi, ça n'a rien de sorcier à faire…
J'aimerais tout de même avoir des avis éclairés sur ce qui est mal pensé ou ce qui pourrait manquer.
Si vous avez des idées…
# Bah...
Posté par Michaël Malter (site web personnel) . Évalué à 1.
Ça m'intéresse…
[^] # Re: Bah...
Posté par max22 . Évalué à 2.
Moi aussi ça m'intéresse, ça te dirait pas d'en faire un journal ?
[^] # Re: Bah...
Posté par flan (site web personnel) . Évalué à 2.
Je vais essayer d'avancer un peu d'abord :)
# Ailleurs...
Posté par lolop (site web personnel) . Évalué à 2.
Skeleton http://pypi.python.org/pypi/skeleton/
Et le très connu Paste http://pythonpaste.org/script/
Au pire ça peut servir pour s'en inspirer.
Votez les 30 juin et 7 juillet, en connaissance de cause. http://www.pointal.net/VotesDeputesRN
# src/
Posté par oao . Évalué à 1. Dernière modification le 18 février 2013 à 16:01.
Il ne faudrait pas privilégier un dossier src/, plutôt que monmodule/ ? Ce serait plus en accord avec les dénominations test/ et doc/, mais pour Django il faut mieux monmodule/.
J'aurai mis data/ à la racine, mais c'est personnel.
[^] # Re: src/
Posté par flan (site web personnel) . Évalué à 1.
Si je ne me trompe pas, le module Python "toto" est toujours dans le dossier toto/, qui contient un fichier toto/__init__.py.
Si je mettais un dossier src/, on se retrouverait avec un dossier src/ contenant uniquement un dossier toto/. Je trouve ça bof.
Quant à data à la racine, c'est nettement moins pratique pour y faire référence. Quand tu as toto/data et toto/__init__.py, data/ est toujours au même niveau que init.py (donc on peut calculer facilement son chemin absolu).
Par contre, si tu mets data/ à la racine, en mode développement data est à init.py/../data. Et quand il sera installé, où est-il ? Aucune idée, mais pas au même niveau en tout cas (vu qu'il serait mélangé avec les autres modules Python).
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.