Question Quelle est la meilleure structure de projet pour une application Python? [fermé]


Imaginez que vous souhaitiez développer une application bureautique non-triviale (pas web) en Python. Quelle est la meilleure façon de structurer la hiérarchie des dossiers du projet?

Les caractéristiques souhaitables sont la facilité de maintenance, la convivialité de l'IDE, la possibilité de ramifier / fusionner le contrôle de la source et la génération facile de paquets d'installation.

En particulier:

  1. Où mettez-vous la source?
  2. Où mettez-vous les scripts de démarrage de l'application?
  3. Où mettez-vous le projet IDE cruel?
  4. Où placez-vous l'unité / tests d'acceptation?
  5. Où mettez-vous des données non-Python telles que les fichiers de configuration?
  6. Où mettez-vous des sources non-Python telles que C ++ pour pyd / so modules d'extension binaires?

572
2017-10-10 21:50


origine


Réponses:


Ça n'a pas trop d'importance. Tout ce qui vous rend heureux fonctionnera. Il n'y a pas beaucoup de règles stupides parce que les projets Python peuvent être simples.

  • /scripts ou /bin pour ce genre d'interface de ligne de commande
  • /tests pour tes tests
  • /lib pour vos bibliothèques en langage C
  • /doc pour la plupart de la documentation
  • /apidoc pour les documents API générés par Epydoc.

Et le répertoire de niveau supérieur peut contenir README, Config et whatnot.

Le choix difficile est d'utiliser ou non /src arbre. Python n'a pas de distinction entre /src, /lib, et /bin comme Java ou C a.

Depuis un niveau supérieur /src Le répertoire est considéré par certains comme dénué de sens, votre répertoire de premier niveau peut être l'architecture de niveau supérieur de votre application.

  • /foo
  • /bar
  • /baz

Je recommande de mettre tout cela sous le répertoire "nom-de-mon-produit". Donc, si vous écrivez une application nommée quux, le répertoire qui contient toutes ces choses est nommé /quux.

Un autre projet PYTHONPATH, alors, peut inclure /path/to/quux/foo réutiliser le QUUX.foo module.

Dans mon cas, depuis que j'utilise Komodo Edit, mon IDE est un seul fichier .KPF. En fait, je l'ai mis au niveau supérieur /quux répertoire, et omettre de l'ajouter à SVN.


303
2017-10-10 22:03



D'après Jean-Paul Calderone Structure du système de fichiers d'un projet Python:

Project/
|-- bin/
|   |-- project
|
|-- project/
|   |-- test/
|   |   |-- __init__.py
|   |   |-- test_main.py
|   |   
|   |-- __init__.py
|   |-- main.py
|
|-- setup.py
|-- README

197
2018-05-13 23:49



Ce article de blog par Jean-Paul Calderone est communément donné comme réponse dans #python sur Freenode.

Structure du système de fichiers d'un projet Python

Faire:

  • nommez le répertoire quelque chose lié à votre projet. Par exemple, si votre projet s'appelle "Twisted", nommez le répertoire racine de ses fichiers source Twisted. Lorsque vous publiez des versions, vous devez inclure un suffixe de numéro de version: Twisted-2.5.
  • créer un répertoire Twisted/bin et mettez vos exécutables là, si vous en avez. Ne leur donnez pas .py extension, même si ce sont des fichiers source Python. Ne mettez pas de code à l'exception d'une importation et d'un appel à une fonction principale définie ailleurs dans vos projets. (Légère ride: puisque sur Windows, l'interpréteur est sélectionné par l'extension du fichier, les utilisateurs de Windows ne veulent pas l'extension .py Donc, quand vous empaquetez pour Windows, vous voudrez peut-être l'ajouter. Je sais d'automatiser ce processus. Considérant que sur POSIX l'extension .py est une seule verrue, alors que sur Windows le manque est un bug réel, si votre base d'utilisateurs inclut des utilisateurs Windows, vous pouvez choisir d'avoir juste le .py extension partout.)
  • Si votre projet est exprimable en un seul fichier source Python, placez-le dans le répertoire et nommez-le quelque chose en rapport avec votre projet. Par exemple, Twisted/twisted.py. Si vous avez besoin de plusieurs fichiers sources, créez plutôt un paquet (Twisted/twisted/, avec un vide Twisted/twisted/__init__.py) et placez vos fichiers sources dedans. Par exemple, Twisted/twisted/internet.py.
  • mettez vos tests unitaires dans un sous-paquetage de votre paquet (note - cela signifie que l'option de fichier source unique Python ci-dessus était une astuce - vous toujours besoin d'au moins un autre fichier pour vos tests unitaires). Par exemple, Twisted/twisted/test/. Bien sûr, en faire un paquet avec Twisted/twisted/test/__init__.py. Placez des tests dans des fichiers comme Twisted/twisted/test/test_internet.py.
  • ajouter Twisted/README et Twisted/setup.py pour expliquer et installer votre logiciel, respectivement, si vous vous sentez bien.

Ne pas:

  • mettre votre source dans un répertoire appelé src ou lib. Cela rend difficile à exécuter sans installation.
  • mettez vos tests en dehors de votre paquet Python. Cela rend difficile l'exécution des tests sur une version installée.
  • créer un package seulement a un __init__.py puis mettez tout votre code dans __init__.py. Il suffit de faire un module au lieu d'un paquet, c'est plus simple.
  • essayez de créer des hacks magiques pour que Python puisse importer votre module ou votre package sans que l'utilisateur ajoute le répertoire le contenant à son chemin d'import (soit via PYTHONPATH, soit par un autre mécanisme). Vous serez ne pas gérer correctement tous les cas et les utilisateurs vont se fâcher contre vous lorsque votre logiciel ne fonctionne pas dans leur environnement.

180
2017-08-05 23:29



Check-out Open Sourcing d'un projet Python dans le bon sens.

Permettez-moi d'extraire le disposition du projet une partie de cet excellent article:

Lors de la configuration d'un projet, la mise en page (ou la structure du répertoire) est importante pour obtenir les bons résultats. Une mise en page judicieuse signifie que les contributeurs potentiels ne doivent pas passer leur temps à chercher un morceau de code. les emplacements de fichiers sont intuitifs. Puisque nous traitons d'un projet existant, cela signifie que vous devrez probablement déplacer certaines choses.

Commençons au sommet. La plupart des projets contiennent un certain nombre de fichiers de niveau supérieur (tels que setup.py, README.md, requirements.txt, etc.). Il y a alors trois répertoires que chaque projet devrait avoir:

  • Un répertoire docs contenant la documentation du projet
  • Un répertoire nommé avec le nom du projet qui stocke le paquet Python réel
  • Un répertoire de test dans l'un des deux endroits   
    • Sous le répertoire du package contenant le code de test et les ressources
    • En tant que répertoire autonome de niveau supérieur   Pour avoir une meilleure idée de l'organisation de vos fichiers, voici un aperçu simplifié de la mise en page de l'un de mes projets, sandman:
$ pwd
~/code/sandman
$ tree
.
|- LICENSE
|- README.md
|- TODO.md
|- docs
|   |-- conf.py
|   |-- generated
|   |-- index.rst
|   |-- installation.rst
|   |-- modules.rst
|   |-- quickstart.rst
|   |-- sandman.rst
|- requirements.txt
|- sandman
|   |-- __init__.py
|   |-- exception.py
|   |-- model.py
|   |-- sandman.py
|   |-- test
|       |-- models.py
|       |-- test_sandman.py
|- setup.py

Comme vous pouvez le voir, il existe des fichiers de premier niveau, un répertoire docs (généré est un répertoire vide où sphinx mettra la documentation générée), un répertoire sandman, et un répertoire de test sous sandman.


94
2017-11-09 02:22



La "Python Packaging Authority" a un exemple de projet:

https://github.com/pypa/sampleproject

Il s'agit d'un exemple de projet d'aide au didacticiel sur l'empaquetage et la distribution de projets du Guide de l'utilisateur de Python Packaging.


16
2018-06-12 09:23



Essayez de démarrer le projet en utilisant le python_boilerplate modèle. Il suit en grande partie les meilleures pratiques (par ex. ceux ici), mais est mieux adapté au cas où vous vous trouvez disposé à diviser votre projet en plus d'un oeuf à un moment donné (et croyez-moi, avec tout sauf les projets les plus simples, vous le ferez.Une situation courante est où vous devez utiliser localement version modifiée de la bibliothèque de quelqu'un d'autre).

  • Où mettez-vous la source?

    • Pour les grands projets décents, il est judicieux de diviser la source en plusieurs œufs. Chaque oeuf irait comme un setuptools-layout séparé sous PROJECT_ROOT/src/<egg_name>.
  • Où mettez-vous les scripts de démarrage de l'application?

    • L'option idéale consiste à enregistrer le script de démarrage de l'application en tant que entry_point dans l'un des oeufs.
  • Où mettez-vous le projet IDE cruel?

    • Cela dépend de l'IDE. Beaucoup d'entre eux gardent leurs affaires PROJECT_ROOT/.<something> à la racine du projet, et c'est bien.
  • Où placez-vous l'unité / tests d'acceptation?

    • Chaque oeuf a un ensemble distinct de tests, conservés dans son PROJECT_ROOT/src/<egg_name>/tests annuaire. Personnellement, je préfère utiliser py.test pour les exécuter.
  • Où mettez-vous des données non-Python telles que les fichiers de configuration?

    • Ça dépend. Il peut y avoir différents types de données non-Python.
      • "Ressources", c'est-à-dire des données qui doivent être emballées dans un œuf. Ces données vont dans le répertoire egg correspondant, quelque part dans l'espace de noms du package. Il peut être utilisé via pkg_resources paquet.
      • "Fichiers de configuration", c'est-à-dire des fichiers non-Python qui doivent être considérés comme externes aux fichiers sources du projet, mais qui doivent être initialisés avec certaines valeurs lorsque l'application commence à s'exécuter. Au cours du développement, je préfère conserver ces fichiers PROJECT_ROOT/config. Pour le déploiement, il peut y avoir plusieurs options. Sur Windows on peut utiliser %APP_DATA%/<app-name>/config, sur Linux, /etc/<app-name> ou /opt/<app-name>/config.
      • Fichiers générés, c'est-à-dire des fichiers qui peuvent être créés ou modifiés par l'application pendant l'exécution. Je préférerais les garder dans PROJECT_ROOT/var au cours du développement, et sous /var pendant le déploiement de Linux.
  • Où mettez-vous des sources non-Python telles que C ++ pour pyd / so modules d'extension binaires?
    • Dans PROJECT_ROOT/src/<egg_name>/native

La documentation irait généralement dans PROJECT_ROOT/doc ou PROJECT_ROOT/src/<egg_name>/doc (Cela dépend si vous considérez certains des œufs comme des grands projets séparés). Une configuration supplémentaire sera dans des fichiers comme PROJECT_ROOT/buildout.cfg et PROJECT_ROOT/setup.cfg.


15
2018-03-21 09:17



D'après mon expérience, c'est juste une question d'itération. Mettez vos données et code partout où vous pensez qu'ils vont. Les chances sont, vous aurez tort de toute façon. Mais une fois que vous avez une meilleure idée de la façon dont les choses vont se former, vous êtes dans une bien meilleure position pour faire ce genre de suppositions.

En ce qui concerne les sources d'extension, nous avons un répertoire de code sous trunk qui contient un répertoire pour python et un répertoire pour diverses autres langues. Personnellement, je suis plus enclin à essayer de placer n'importe quel code d'extension dans son propre dépôt la prochaine fois.

Cela dit, je reviens à mon point de départ: n'en faites pas trop. Mettez-le quelque part qui semble fonctionner pour vous. Si vous trouvez quelque chose qui ne fonctionne pas, il peut (et devrait) être changé.


13
2017-10-10 22:57



Les données non-python sont mieux regroupées dans vos modules Python en utilisant package_data soutien dans setuptools. Une chose que je recommande fortement est d'utiliser des paquets d'espace de noms pour créer des espaces de noms partagés que plusieurs projets peuvent utiliser - un peu comme la convention de Java de placer des paquets dans com.yourcompany.yourproject(et être en mesure d'avoir un partage com.yourcompany.utils espace de noms).

Re branchement et la fusion, si vous utilisez un système de contrôle de source assez bon, il va gérer les fusions, même à travers les renommages; Bazar est particulièrement bon à cela.

Contrairement à d'autres réponses ici, je suis +1 à avoir un src répertoire de haut niveau (avec doc et test répertoires à côté). Les conventions spécifiques pour les arborescences de répertoires de documentation varient en fonction de ce que vous utilisez; Sphinx, par exemple, a ses propres conventions que son outil de démarrage rapide prend en charge.

S'il vous plaît, s'il vous plaît tirer parti de setuptools et pkg_resources; cela permet à d'autres projets de s'appuyer plus facilement sur des versions spécifiques de votre code (et pour que plusieurs versions soient installées simultanément avec différents fichiers non-code, si vous utilisez package_data).


7
2017-10-10 22:39