Les projets python ont-ils besoin d'un MANIFEST.in et que devrait-il contenir?

120

Le guide "Python Distribute" (était sur python-distribute.org, mais l'enregistrement est arrivé à expiration) me dit d'inclure les doc/txtfichiers et les .pyfichiers sont exclus du MANIFEST.infichier

La documentation de sourcedist m'indique que sdist utilise MANIFEST.inet n'inclut que les fichiers que vous spécifiez et d'inclure des .pyfichiers. Il me dit aussi d'utiliser: python setup.py sdist --manifest-onlypour générer un MANIFEST, mais python me dit que cela n'existe pas

J'apprécie qu'ils proviennent de différentes versions de python et que le système de distribution est dans un désordre complet, mais en supposant que j'utilise python 3 et setuptools(le nouveau qui inclut distribuer mais maintenant appelé setuptools, pas l'ancien setuptools qui était obsolète pour les outils de distribution uniquement être ramené dans la distribution et la distribution renommée setuptools .....)

et je suis la structure de dossier et le setup.pyfichier «standard» ,

Ai-je besoin d'un MANIFEST.in?
Que devrait-il y avoir?
Quand tous ces différents systèmes et méthodes d'emballage seront-ils transformés en un seul processus simple?

python setuptools

— Neil Walker
source

Réponses:

117

Re: "Ai-je besoin d'un MANIFEST.in?

Non, vous n'êtes pas obligé d'utiliser MANIFEST.in. Les deux, distutilset setuptoolsincluent dans le package de distribution source tous les fichiers mentionnés dans setup.py- les modules, les fichiers python du package README.txtet test/test*.py. Si c'est tout ce que vous voulez avoir dans le package de distribution, vous n'avez pas à utiliser MANIFEST.in.

Si vous souhaitez manipuler (ajouter ou supprimer) les fichiers par défaut à inclure, vous devez utiliser MANIFEST.in.

Re: Que devrait-il y avoir?

La procédure est simple:

Assurez-vous que setup.pyvous incluez (au moyen d' setuparguments) tous les fichiers que vous jugez importants pour l'exécution du programme (modules, packages, scripts ...)
Précisez s'il y a des fichiers à ajouter ou des fichiers à exclure. Si ni l'un ni l'autre n'est nécessaire, il n'est pas nécessaire d'utiliser MANIFEST.in.
Si MANIFEST.innécessaire, créez-le. Habituellement, vous y ajoutez des tests*/*.pyfichiers, README.rstsi vous n'utilisez pas README.txt, des docsfichiers et éventuellement des fichiers de données pour la suite de tests, si nécessaire.

Par exemple:

include README.rst
include COPYING.txt

Pour le tester, exécutez python setup.py sdistet examinez l'archive tar créée sous dist/.

Quand tous ces différents systèmes de paquets ...

Comparer la situation d'aujourd'hui à celle d'il y a 2 ans - la situation est bien meilleure - setuptoolsest la voie à suivre. Vous pouvez ignorer le fait, distutilsest un peu cassé et est une base de bas niveau setuptoolscar il setuptoolsfaudra prendre soin de vous cacher ces choses.

EDIT : Les derniers projets que j'utilise pbrpour créer des packages de distribution avec trois lignes setup.pyet le reste étant dans setup.cfget requirements.txt. Pas besoin de s'inquiéter MANIFEST.inet d'autres choses étranges. Même si le paquet mériterait un peu plus de documentation. Voir http://docs.openstack.org/developer/pbr/

— Jan Vlcinsky
source

D'après mon expérience limitée, il semble que si vous souhaitez inclure des fichiers qui ne sont pas à l'intérieur d'un module python (dir avec init .py), vous devez utiliser MANIFEST.in et utiliser la commande sdist(means: source distribution ). Si vous considérez cela bdistet bdist_wheelsont binaires et destinés uniquement à être installés dans votre chemin python, cela a du sens. (Où iraient ces fichiers et répertoires non-module? Dans /usr/local/lib/python2.7/dist-packages/? Sûrement pas.) Mais cela vaut la peine d'être mentionné car il est déroutant de voir l'archive créée et de ne pas inclure les fichiers.

— Bruno Bronosky

Pour éviter les inévitables package_dataet les data_filesrecommandations, qui sont hors de portée, je vais continuer. package_datarépertorie les fichiers installés avec votre package dans dist-packages/yourpackagelesquels ils auraient été ignorés car ils n'ont pas de nom * .py. data_filesrépertorie les fichiers installés en dehors de votre package. Chaque entrée spécifie un chemin cible avec le préfixe sys.prefixs'il est relatif ou créé directement (si les autorisations le permettent) s'il commence par un /.

— Bruno Bronosky

@JanVlcinsky il est important de savoir ce qui est et [plus important] n'est pas inclus dans différents formats de distribution. J'ai un projet public que je distribue uniquement via la distribution source car j'inclus un fichier boto.sample.cfg (qui contient un faux identifiant AWS IAM) en dehors du package (à la racine) et les distributions binaires ne l'incluront pas. Je crée des versions binaires privées pour le déploiement en production qui ont data_files = [('/ etc /', ['boto.cfg'])]. Si vous souhaitez distribuer des fichiers non-py, vous devez savoir comment cela fonctionne.

— Bruno Bronosky

@MichaelGoerz Honnêtement, ils ne devraient pas. Cette réponse est ancienne et suggérer pbrest également une mauvaise idée.

— Arne

@Ame je suis d'accord, les choses ont évolué. Actuellement, je convertis la plupart de mes projets de pbr à la poésie

— Jan Vlcinsky

Ancienne question, nouvelle réponse:

Non, vous n'en avez pas besoin MANIFEST.in. Cependant, pour arriver setuptoolsà faire ce que vous entendez (habituellement), vous devez utiliser le setuptools_scm, qui joue le rôle de MANIFEST.inà 2 endroits clés:

Il garantit que tous les fichiers pertinents sont empaquetés lors de l'exécution de la sdistcommande (où tous les fichiers pertinents sont définis comme «tous les fichiers sous contrôle de code source»)
Lors de l' utilisation include_package_datad'inclure des données de paquets dans le cadre du buildou bdist_wheel. (encore une fois: fichiers sous contrôle de code source)

La compréhension historique de MANIFEST.inest la suivante: lorsque vous n'avez pas de système de contrôle de source, vous avez besoin d'un autre mécanisme pour faire la distinction entre les «fichiers source» et les «fichiers qui se trouvent dans votre répertoire de travail». Cependant, votre projet est sous contrôle de code source (à droite ??), il n'est donc pas nécessaire d'utiliser MANIFEST.in. Plus d'informations dans cet article .

— Klaas van Schelven
source