Déploiement d'une application python avec un 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 interface de ligne de commande à la fonctionnalité implémentée dans
2. Une bibliothèque installée où que se trouve le répertoire site-packages actuel.

Actuellement, j'ai la structure de répertoires suivante dans mes sources:

foo.py
foo/
  __init__.py
  ...

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

La question est donc de savoir quelle est la pratique habituelle pour orchestrer de telles situations. Une des choses à laquelle je pouvais penser est, lors de l’installation, renommer foo.py en just foo, ce qui l’empêche de s’importer lui-même, mais cela semble plutôt gênant ...

Une autre partie du problème, je suppose, est qu’il s’agit d’un défi de dénomination. Peut-être appeler le script exécutable foo-bin.py?

Answer 1

Cet article est très bon et vous indique comment le faire. Le deuxième élément de la liste Do répond à votre question.

copier-coller sans vergogne:

  

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

     

par Jp Calderone

     

Faites:

     

  
• nommez le répertoire quelque chose en rapport avec votre projet. Par exemple, si votre   le projet est nommé "Twisted", nommez le   répertoire de niveau supérieur pour sa source   fichiers Twisted . Quand tu libères,   vous devriez inclure un numéro de version   suffixe: Twisted-2.5 .
  
• créez un répertoire Twisted / bin et placez-y vos exécutables, si vous le souhaitez.   en avoir. Ne leur donnez pas un .py   extension, même si elles sont en Python   fichiers source. Ne mettez aucun code dans   eux, sauf une importation et appel à un   fonction principale définie ailleurs   dans vos projets.
  
• Si votre projet est exprimable en tant que fichier source Python unique, alors mettez-le   dans le répertoire et nommez-le   quelque chose lié à votre projet. Pour   Par exemple, Twisted / twisted.py . Si vous   besoin de plusieurs fichiers sources, créez un   package à la place ( Twisted / twisted / ,   avec un vide    Twisted / twisted / __ init __. py ) et placez   vos fichiers source dedans. Par exemple,    Twisted / twisted / internet.py .
  
• placez vos tests unitaires dans un sous-package de votre package (remarque - cela signifie   que le fichier source unique Python   L’option ci-dessus était une astuce - vous avez toujours   besoin d'au moins un autre fichier pour votre   tests unitaires). Par exemple,    Twisted / twisted / test / . Bien sûr, faire   c'est un paquet avec    Twisted / twisted / test / __ init __. py .   Placez les tests dans des fichiers comme    Twisted / twisted / test / test_internet.py .
  
• ajoutez Twisted / README et Twisted / setup.py pour expliquer et   installez votre logiciel, respectivement,   si vous vous sentez bien.
  

     

Ne pas:

     

  
• placez votre source dans un répertoire appelé src ou lib . Cela rend difficile   exécuter sans installer.
  
• placez vos tests en dehors de votre paquet Python. Cela rend difficile de   exécuter les tests sur un installé   version.
  
• créez un package ne contenant qu'un __ init __. py , puis placez tout votre code dans __ init __. py . Juste faire un module   au lieu d’un paquet, c’est plus simple.
  
• essayez de créer des hacks magiques pour permettre à Python d'importer votre module   ou un paquet sans avoir l'utilisateur ajouter   le répertoire le contenant à leur   chemin d’importation (via PYTHONPATH ou   un autre mécanisme). Tu ne vas pas   gérer correctement tous les cas et les utilisateurs   se fâcher contre vous quand votre   le logiciel ne fonctionne pas dans leur   environnement.
  

Answer 2

Distutils prend en charge l’installation de modules, de packages et de scripts. . Si vous créez un setup.py distutils qui fait référence à foo en tant que package et à foo.py en tant que script, alors foo. py doit être installé dans / usr / local / bin ou quel que soit le chemin d'installation du script approprié situé sur le système d'exploitation cible, et le package toto doit être installé dans le répertoire site_packages .

Answer 3

Vous devez appeler l'exécutable uniquement foo , et non foo.py . Les tentatives d'importation de foo ne l'utiliseront pas.

Quant à la nommer correctement: il est difficile de répondre de manière abstraite; nous aurions besoin de savoir ce que cela fait spécifiquement. Par exemple, s'il configure et contrôle, l'appeler -config ou ctl peut convenir. S'il s'agit d'une API shell pour la bibliothèque, elle devrait porter le même nom que la bibliothèque.

Answer 4

Votre module CLI est une chose, le package qui la prend en charge en est une autre. 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 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 courant.