Avec le temps, je me suis rendu compte que faire un projet Python bien propre n'était pas si facile que ça, il faut écrire les tests unitaires, utiliser gettext pour les traductions, avoir un fichier setup.py (équivalent de Makefile) pour l'installation ou la génération de paquets (setup.exe, .deb, .rpm, …), préparer la doc pour la générer facilement, utiliser pkg_resources au lieu d'accéder directement aux fichiers (pour les icônes, par exemple), etc.
Au final, ce boulot doit être refait à chaque nouveau projet. Et comme je suis un grand flemmard, je n'aime pas faire deux fois le même boulot…
Du coup, je me suis lancé dans StarterPyth, qui pose quelques questions (nom du projet, version de Python choisie, faut-il être compatible avec Python 3, …) avant de générer ces fichiers.
Accessoirement, il propose de faire un squelette de package Python tout simple, mais aussi une appli en ligne de commande ou un site web via Django.
Et comme je me suis dit que ça pouvait intéresser du monde, j'ai mis tout ça sur Github ^
https://github.com/d9pouces/StarterPyth
Après installation, cela rajoute quelques commandes aux fichiers setup.py (pour générer la documentation, lancer les tests unitaires, générer les fichiers de localisation, générer des fichiers de pseudo-localisation, calculer les dépendances, tester la documentation, etc.)
Pour l'installer, le plus simple est de passer par pip
pip install starterpyth
starterpyth-bin
[répondre aux questions]
La doc est encore loin d'être complète, d'autant que j'aimerais en profiter pour faire un petit résumé pour faire un bon petit package Python. Le code généré a encore besoin d'être amélioré, afin de partir sur de bonnes bases :)
# Pas de Python 3 ?
Posté par Anonyme . Évalué à 3. Dernière modification le 27 août 2013 à 22:15.
En essayant dans un virtualenv sous Python 3, plantages & co. J’en déduis que le projet n'est pas compatibles Python 3, ça me paraît un peu étonnant vu que l’outil propose de créer des projets compatibles 2 et 3 :D
Au passage, pourrait-on avoir les licences MIT et BSD au programme ?
[^] # Re: Pas de Python 3 ?
Posté par flan (site web personnel) . Évalué à 4.
Tiens, c'est curieux, je le teste avec Python 3.2 pourtant.
Va falloir que je teste avec d'autres Python3, alors :-(
Va falloir que je mette à jour ma liste de tests (c'est assez malpratique à tester, vu qu'il faut tester le resultat de plusieurs générations de code, avec plusieurs versions de Python, et généré depuis plusieurs versions de Python …)
[^] # Re: Pas de Python 3 ?
Posté par Anonyme . Évalué à 4.
Oui, en faisant un petit tour du propriétaire je me suis rendu compte que python 3.3 ne figure pas dans la liste de tests, et c’est cette version que j’utilise.
[^] # Re: Pas de Python 3 ?
Posté par flan (site web personnel) . Évalué à 1.
Résultat des courses, je pense que je vais devoir installer les Python qui manquent (3.0, 3.1, 3.3, 3.4).
[^] # Re: Pas de Python 3 ?
Posté par saimn . Évalué à 1.
Travis est bien pratique pour ça, et bien intégré à github (pratique pour tester les pull requests). Sinon il y a tox, mais ça nécessite d'avoir les différentes versions installlées sur ta machine.
Pour 3.0 et 3.1 tu peux les oublier, ça doit être vraiment très peu utilisé, et même 3.2, à part debian stable …
[^] # Re: Pas de Python 3 ?
Posté par Anonyme . Évalué à 2.
3.2 on en rencontre encore assez pour que ça soit intéressant de garder des tests dessus. Sinon oui pour le reste…
[^] # Re: Pas de Python 3 ?
Posté par flan (site web personnel) . Évalué à 1.
Bon, je devrais avoir corrigé les différents bugs signalés, et j'ai au passage largement augmenté les tests…
Maintenant, je me retrouve à tester l'exécutable avec Python 2.6/2.7/3.0/3.2/3.3/3.4, pour générer du code pour 2.6 « pur », 2.6 + six, 2.6 + 2to3, 2.7 « pur », 2.7 + six, 2.7 + 2to3, 3.0, 3.1, 3.2, 3.3, 3.4, et à tester le résultat obtenu avec les différentes versions compatibles.
Sachant qu'en plus, il faut tester avec ou sans i18n… Ça commence à faire beaucoup de combinaisons.
[^] # Re: Pas de Python 3 ?
Posté par flan (site web personnel) . Évalué à 2.
J'ai pu regarder un peu pour Python 3.3, et je me demande s'il n'y a pas un bug dans la version de distribute.
Concrètement, je dis que mon package peut-être installé sous la forme d'une archive zip (j'utilise les bonnes fonctions pour accéder aux ressources). Quand je désactive ce paramètre (zip_safe=False dans setup.py), ça fonctionne nickel avec Python 3.3. Quand je le mets à True, ça marche sauf avec Python 3.3…
Je vais regarder pour l'installation manuelle via setup.py install, mais demain soir :D
# cookiecutter
Posté par saimn . Évalué à 4.
Dans le même genre, un projet sorti récemment (enfin j'ai pas testé mais il me semble que c'est assez proche) : https://github.com/audreyr/cookiecutter
[^] # Re: cookiecutter
Posté par flan (site web personnel) . Évalué à 2.
Je ne connaissais pas (pourtant, j'avais cherché ! ).
Son projet permet plus de choses (plus de langages différents), mais au niveau Python il est plus limité : j'ajoute différentes commands pour le setup.py, je prépare l'internationalisation du projet, différentes façons d'être compatible avec Python 3, etc.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.