Organisation des projets

Bonjour à tous,

Je vous sollicite aujourd'hui concernant l'organisation des scripts. En effet, je développe maintenant depuis quelques années et je suis en train de porter mes script en 3.5 je souhaite en profiter également pour réorganiser l’architecture de mes projets.

Utilisant Pydev, j'ai pour habitude ce créer un projet avec quelques sous-dossiers \dev pour "en développement"t et \prod pour "en production" de la façon suivante :
MonProjet
---\dev\script1.py
---\dev\script2.py
---\dev\script3.py
---\prod\script1.py
---\prod\script2.py
---\prod\script3.py

mes projets sont simples 15 scripts max (+/- 300 lignes), en googlant j'ai trouvé quelques conseils mais ils me sembles surtout adapté aux gros projets, je souhaite connaître votre avis et les bonnes pratiques.

Merci

Salut,

Personnellement, je ne fais pas de différence dev~prod mais c'est parce que mes applications sont versionnées sur une forge.

Donc j'ai simplement un arbre comme ceci:

projet/
-------docs/
-------testdivers/
-------backups/
-------autres/
-------trunk/
--------------l'ensemble de l'application versionnée

En fait, tout ce qui est voisin de trunk est la partie dev (lire boxon) et ce qui est dans trunk est la partie "propre".

Je crois que c'est plus une question d'habitude qu'une règle de travail.

Salut,

Citation:

---

Envoyé par jouclar

mes projets sont simples 15 scripts max (+/- 300 lignes), en googlant j'ai trouvé quelques conseils mais ils me sembles surtout adapté aux gros projets, je souhaite connaître votre avis et les bonnes pratiques.

---

"les bonnes pratiques" dépendent d'un contexte. Imaginez que vous ayez à faire faire votre boulot par une autre personne, vous allez devoir lui expliquer votre organisation et les pièges qu'elle vous évite: ce seront les bonnes pratiques pour gérer le code de jouclar. Pas de quoi faire un bouquin, mais bonnes pratiques quand même.

Dans les gros projets, il y a beaucoup de développeurs qui vont et qui viennent. Si on ne veut pas que ce soit le souk, on est bien obligé d'imposer quelques règles communes que l'on va écrire dans des documents et améliorer au cours du temps. C'est ce qui fait qu'il y a de la littérature la dessus dont on peut éventuellement s'inspirer.

Cela dit comme vous développez de petites applications Python, vous avez deux domaines de "bonnes pratiques": celles que pourra avoir un développeur en général et celles plus spécifiques à Python.

développeur en général

Si vous utilisez PyDev, vous utilisez Eclipse. Vous avez la possibilité d'y intégrer un gestionnaire de configuration comme SVN, GIT ou mercurial.
Plus besoin d'avoir un répertoire "prod": vous gelez l'état correspondant (modalités différentes selon l'outil) et revenir dessus via l'historique (par exemple).
Mais... c'est un (petit) investissement (apprendre à s'en servir)
personnellement, j'utilise aussi PyDev avec Git ou mercurial suivant le cas.

côté Python.

Il faut essayer de construire ses applications via le mécanisme de packaging "python" (çà aide aussi à faire le suivi et la mise à jour de ce qui a été installé en production). Jusqu'à la version 3.5, c'était distutils qui est remplacé par Python Packaging User Guide. que vous pouvez adopter tout ou partie... et qui impose une structure "standard" à vos divers projets.
note: ouvre que ce soit une "bonne pratique" documentée, s'appliquer à suivre ces standards facilite l'utilisation de packaging comme cx_freeze ou autre. Ce que je fais souvent car version de Python et bibliothèques installées sur les cibles ne sont pas forcément "à jour" et un .msi ou un .deb est plus facile à déployer en production que passer par easy_install ou pip.

- W

Merci à tous les deux pour vos précieux conseils.

Je pense que je vais apprendre à utiliser Git via Eclipse et le Python Packaging sauf que pour un non informaticien formé sur le tas au gré des besoins de son entreprise (1x tous les 6 mois) cela n'a pas l'air simple:calim2:

Citation:

---

Envoyé par jouclar

Je pense que je vais apprendre à utiliser Git via Eclipse et le Python Packaging sauf que pour un non informaticien formé sur le tas au gré des besoins de son entreprise (1x tous les 6 mois) cela n'a pas l'air simple:calim2:

---

Ben çà vous donnera l'occasion de poster des questions intéressantes sur le forum :lol:

- W