Déploiement d'une application python avec package partagé

Question

Je pense comment organiser une application python déployée qui aura un

1. script exécutable situé dans/usr/bin/qui fournira une CLI aux fonctionnalités mises en œuvre dans
2. Une bibliothèque installée à l'emplacement du répertoire actuel des packages de site.

Maintenant, actuellement, j'ai la structure de répertoire suivant dans mes sources:

foo.py 
foo/ 
    __init__.py 
    ... 

que je suppose est pas la meilleure façon de faire les choses. Au cours du développement, tout fonctionne comme prévu, mais quand il est déployé, le code "from foo import FooObject" dans foo.py tente apparemment d'importer lui-même foo.py, ce qui n'est pas le comportement que je recherche.

Donc la question est quelle est la pratique standard d'orchestrer des situations comme celle-ci? Une des choses que je pourrais penser est, lors de l'installation, renommez foo.py juste foo, ce qui l'arrête de l'importer, mais cela semble plutôt maladroit ...

Une autre partie du problème, je suppose, est que c'est un défi de nommage. Peut-être appelez le script exécutable foo-bin.py?

Answer 1

This article est assez bon, et vous montre un bon moyen de le faire. Le deuxième élément de la liste Do répond à votre question.

sans vergogne copier coller:

Structure Filesystem d'un projet Python

par Jp Calderone

Do:

• nommez le répertoire quelque chose lié à votre projet. Par exemple, si votre projet est nommé "Twisted", nommez le répertoire de premier niveau pour sa source fichiers Twisted. Lorsque vous publiez des versions, , vous devez inclure un numéro de version suffixe: Twisted-2.5.
• créer un répertoire Twisted/bin et y mettre vos exécutables, si vous en avez. Ne leur donnez pas une extension .py , même s'il s'agit de fichiers source Python . Ne mettez pas de code dans sauf une importation et un appel à une fonction principale définie ailleurs dans vos projets.
• Si votre projet est exprimable en tant que fichier source Python unique, placez-le dans le répertoire et nommez-le comme étant lié à votre projet. Pour l'exemple , Twisted/twisted.py. Si vous avez besoin de plusieurs fichiers source, créez un package à la place (Twisted/twisted/, avec un vide Twisted/twisted/__init__.py) et placez vos fichiers source en elle. Par exemple, Twisted/twisted/internet.py.
• mettre vos tests unitaires dans un sous-ensemble de votre forfait (note - cela signifie que l'option fichier source Python unique ci-dessus était un truc - vous avez toujours besoin d'au moins un autre fichier pour vos tests unitaires). Par exemple, Twisted/twisted/test/. Bien sûr, faites un paquet avec Twisted/twisted/test/__init__.py. Placer des tests dans des fichiers comme Twisted/twisted/test/test_internet.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 de fonctionner 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 qui a seulement 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.
• essayer de trouver des hacks magiques pour faire Python en mesure d'importer votre module ou package sans avoir l'utilisateur d'ajouter le répertoire contenant à leur chemin d'importation (soit par PYTHONPATH ou un autre mécanisme). Vous ne serez 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 .

Answer 2

Vous devez appeler l'exécutable simplement foo, et non foo.py, puis les tentatives d'importation de foo ne l'utiliseront pas. Comme pour le nommer correctement: il est difficile de répondre dans l'abstrait; nous aurions besoin de savoir ce qu'il fait exactement. Par exemple, s'il configure et contrôle, l'appeler -config ou ctl pourrait être approprié. S'il s'agit d'une API shell pour la bibliothèque, elle doit avoir le même nom que la bibliothèque.

Answer 3

Distutils prend en charge l'installation de modules, de packages et de scripts. Si vous créez un distutils setup.py qui fait référence à foo comme un paquet et foo.py comme un script, puis foo.py devrait obtenir installé à /usr/local/bin ou quel que soit le chemin d'installation script approprié est le système d'exploitation cible, et le paquet foo devrait obtenir installé dans le répertoire site_packages .

Answer 4

Votre module CLI est une chose, le package qui le supporte est une autre chose. Ne confondez pas les noms avec le module foo (dans un fichier foo.py) et le paquet foo (dans un répertoire foo avec un fichier __init__.py).

Vous avez deux choses nommées foo: un module et un package. Que voulez-vous nommer d'autre foo? Une classe? Une fonction? Une variable?

Choisissez un nom distinctif pour le module foo ou le paquet foo. foolib, par exemple, est un nom de package populaire.