I progetti python hanno bisogno di un MANIFEST.in e cosa dovrebbe esserci?

120

La guida "Python Distribute" (era su python-distribute.org, ma la registrazione è scaduta) mi dice di includere doc/txtfile e i .pyfile sono esclusi nel MANIFEST.infile

La documentazione di sourcedist mi dice che solo sdist utilizza MANIFEST.ine include solo i file specificati e di includere .pyfile. Mi dice anche di usare: python setup.py sdist --manifest-onlyper generare un MANIFEST, ma python mi dice che questo non esiste

Apprezzo che provengano da diverse versioni di python e il sistema di distribuzione è in un disastro completo, ma supponendo che io stia usando python 3 e setuptools(il nuovo che include distribute ma ora chiamato setuptools, non il vecchio setuptools che era deprecato solo per gli strumenti di distribuzione da riportare in distribute e distribuire rinominato in setuptools .....)

e seguo la struttura delle cartelle e il setup.pyfile "standard" ,

Ho bisogno di un MANIFEST.in?
Cosa dovrebbe esserci dentro?
Quando tutti questi diversi sistemi e metodi di pacchetti saranno trasformati in un unico semplice processo?

python setuptools

— Neil Walker
fonte

Risposte:

117

Ri: "Ho bisogno di un MANIFEST.in?

No, non devi usare MANIFEST.in. Entrambi distutilse setuptoolsstanno includendo nel pacchetto di distribuzione del codice sorgente tutti i file menzionati in setup.py- modules, pacchetto di file python README.txte test/test*.py. Se questo è tutto ciò che vuoi avere nel pacchetto di distribuzione, non devi usarlo MANIFEST.in.

Se vuoi manipolare (aggiungere o rimuovere) i file predefiniti da includere, devi usare MANIFEST.in.

Ri: Cosa dovrebbe esserci dentro?

La procedura è semplice:

Assicurati setup.pydi includere (tramite setupargomenti) tutti i file che ritieni importanti per l'esecuzione del programma (moduli, pacchetti, script ...)
Chiarire se ci sono alcuni file da aggiungere o alcuni file da escludere. Se nessuno dei due è necessario, non è necessario utilizzarlo MANIFEST.in.
Se MANIFEST.inè necessario, crealo. Di solito, aggiungi tests*/*.pyfile, README.rstse non li usi README.txt, docsfile ed eventualmente alcuni file di dati per la suite di test, se necessario.

Per esempio:

include README.rst
include COPYING.txt

Per provarlo, esegui python setup.py sdisted esamina il tarball creato sotto dist/.

Quando saranno tutti questi diversi sistemi di pacchetti ...

Confrontare la situazione oggi e 2 anni fa - la situazione è molto migliore - setuptoolsè la strada da percorrere. Puoi ignorare il fatto, distutilsè un po 'rotto ed è di basso livello setuptoolsperché setuptoolssi prenderà cura di nasconderti queste cose.

EDIT : Ultimi progetti che uso pbrper creare pacchetti di distribuzione con tre righe setup.pye resto in setup.cfge requirements.txt. Non c'è bisogno di preoccuparsi MANIFEST.ine altre cose strane. Anche se il pacchetto meriterebbe un po 'più di documentazione. Vedi http://docs.openstack.org/developer/pbr/

— Jan Vlcinsky
fonte

Nella mia esperienza limitata sembra che se vuoi includere file non all'interno di un modulo python (dir con init .py), devi usare MANIFEST.in e usare il comando sdist(means: source distribution ). Se lo consideri bdiste lo bdist_wheelsei binari e intesi solo per essere installati nel tuo percorso python, questo ha senso. (Dove andrebbero a finire questi file e directory non di modulo /usr/local/lib/python2.7/dist-packages/? Sicuramente no.) Ma vale la pena menzionarlo poiché è confuso vedere l'archivio creato e loro non includono i file.

— Bruno Bronosky

Per evitare l'inevitabile package_datae le data_filesraccomandazioni, che sono fuori portata, continuerò. package_dataelenca i file che vengono installati con il pacchetto in dist-packages/yourpackagecui sarebbero stati ignorati perché non hanno un nome * .py. data_fileselenca i file che vengono installati al di fuori del pacchetto. Ciascuna voce specifica un percorso di destinazione preceduto dasys.prefix se è relativo o creato direttamente (autorizzazioni permettendo) se inizia con un /.

— Bruno Bronosky

@JanVlcinsky è importante sapere cosa è e [cosa più importante] non è incluso in diversi formati di distribuzione. Ho un progetto pubblico che distribuisco solo tramite la distribuzione del codice sorgente perché includo un file boto.sample.cfg (che contiene una falsa credenziale AWS IAM) all'esterno del pacchetto (alla radice) e le distribuzioni binarie non lo includeranno. Realizzo build binari privati per la distribuzione in produzione che hanno data_files = [('/ etc /', ['boto.cfg'])]. Se vuoi distribuire file non py, devi sapere come funzionano queste cose.

— Bruno Bronosky

@MichaelGoerz Onestamente, non dovrebbero. Questa risposta è antica e anche suggerire pbrè una cattiva idea.

— Arne

@Ame sono d'accordo, le cose sono andate avanti. Attualmente sto convertendo la maggior parte dei miei progetti da pbr a poesia

— Jan Vlcinsky

Vecchia domanda, nuova risposta:

No, non ti serve MANIFEST.in. Tuttavia, per setuptoolsfare ciò che (di solito) intendi, devi usare setuptools_scm, che assume il ruolo di MANIFEST.inin 2 punti chiave:

Assicura che tutti i file rilevanti vengano impacchettati durante l'esecuzione del sdistcomando (dove tutti i file rilevanti sono definiti come "tutti i file sotto il controllo del codice sorgente")
Quando si utilizza include_package_dataper includere i dati del pacchetto come parte di buildo bdist_wheel. (di nuovo: file sotto il controllo del codice sorgente)

La comprensione storica di MANIFEST.inè: quando non si dispone di un sistema di controllo del codice sorgente, è necessario un altro meccanismo per distinguere tra "file sorgente" e "file che si trovano nella directory di lavoro". Tuttavia, il tuo progetto è sotto il controllo del codice sorgente (giusto ??), quindi non ce n'è bisogno MANIFEST.in. Maggiori informazioni in questo articolo .

— Klaas van Schelven
fonte