Czy projekty w Pythonie wymagają pliku MANIFEST.in i co powinno się w nim znaleźć?

120

Przewodnik „Python Distribute” (był na python-distribute.org, ale rejestracja wygasła) mówi mi, żebym dołączyć doc/txtpliki, a .pypliki są wykluczane z MANIFEST.inpliku

Dokumentacja sourcedist mówi mi tylko, że sdist używa MANIFEST.ini zawiera tylko określone przez ciebie .pypliki i pliki do dołączenia . Mówi mi również, żebym użył: python setup.py sdist --manifest-onlydo wygenerowania a MANIFEST, ale Python mówi mi, że to nie istnieje

Doceniam to, że pochodzą z różnych wersji Pythona, a system dystrybucji jest w kompletnym bałaganie, ale zakładając, że używam Pythona 3 i setuptools(nowy, który zawiera dystrybucję, ale teraz nazywa się setuptools, a nie stare setuptools, które zostało wycofane tylko z narzędzi do dystrybucji do przywrócenia do dystrybucji i dystrybucji zmieniono nazwę na setuptools .....)

i trzymam się „standardowej” struktury folderów i setup.pyplików,

  1. Czy potrzebuję MANIFEST.in?
  2. Co w nim powinno być?
  3. Kiedy wszystkie te różne systemy i metody pakietów zostaną połączone w jeden prosty proces?
python setuptools Neil Walker
źródło

Odpowiedzi:

117

Odp .: „Czy potrzebuję MANIFESTU.in?

Nie, nie musisz używać MANIFEST.in. Oba, distutilsi setuptoolszawierają w pakiecie dystrybucyjnym źródła wszystkie pliki wymienione w setup.py- moduły, pliki pakietu Python README.txti test/test*.py. Jeśli to wszystko, co chcesz mieć w pakiecie dystrybucyjnym, nie musisz używać MANIFEST.in.

Jeśli chcesz manipulować (dodawać lub usuwać) domyślne pliki do dołączenia, musisz użyć MANIFEST.in.

Re: Co powinno w nim być?

Procedura jest prosta:

  1. Upewnij się, setup.pyże dołączasz (za pomocą setupargumentów) wszystkie pliki, które uważasz za ważne dla uruchomienia programu (moduły, pakiety, skrypty ...)

  2. Wyjaśnij, czy są jakieś pliki do dodania lub pliki do wykluczenia. Jeśli żadne z nich nie jest potrzebne, nie ma potrzeby używania MANIFEST.in.

  3. W MANIFEST.inrazie potrzeby utwórz go. Zwykle dodajesz tam tests*/*.pypliki, README.rstjeśli nie używasz README.txt, docspliki i prawdopodobnie niektóre pliki danych dla zestawu testów, jeśli to konieczne.

Na przykład:

include README.rst
include COPYING.txt

Aby to przetestować, uruchom python setup.py sdisti sprawdź archiwum utworzone pod dist/.

Kiedy te wszystkie różne systemy pakietów ...

Porównanie sytuacji obecnej i 2 lata temu - sytuacja jest znacznie lepsza - setuptoolsto droga do zrobienia. Możesz zignorować ten fakt, distutilsjest trochę zepsuty i jest niskopoziomową podstawą, setuptoolsponieważ setuptoolspowinieneś zadbać o ukrywanie tych rzeczy przed tobą.

EDYCJA : Ostatnie kilka projektów, których używam pbrdo budowania pakietów dystrybucyjnych z trzema wierszami setup.pyi resztą w setup.cfgi requirements.txt. Nie musisz się przejmować MANIFEST.ini innymi dziwnymi rzeczami. Mimo że pakiet zasługiwałby na nieco więcej dokumentacji. Zobacz http://docs.openstack.org/developer/pbr/

Jan Vlcinsky
źródło
1
Z mojego ograniczonego doświadczenia wynika, że ​​jeśli chcesz dołączyć pliki spoza modułu Pythona (katalog z init .py), musisz użyć MANIFEST.in i użyć polecenia sdist(oznacza: dystrybucję źródła ). Jeśli weźmiesz pod uwagę to bdisti bdist_wheelsą binarne i przeznaczone do zainstalowania tylko w Twojej ścieżce Pythona, ma to sens. (Gdzie miałyby się znaleźć te nie-modułowe pliki i katalogi? Na /usr/local/lib/python2.7/dist-packages/pewno nie.) Ale warto o tym wspomnieć, ponieważ mylące jest zobaczenie utworzonego archiwum i nie zawiera on plików.
Bruno Bronosky
7
Aby uniknąć nieuniknionych package_datai data_fileszaleceń, które są poza zakresem, będę kontynuować. package_datawyświetla listę plików, które są instalowane z pakietem, do dist-packages/yourpackagektórych zostałyby pominięte, ponieważ nie mają nazwy * .py. data_fileswyświetla listę plików, które są instalowane poza pakietem. Każdy wpis określa ścieżkę docelową poprzedzoną prefiksem, sys.prefixjeśli jest względna lub utworzona bezpośrednio (w zależności od uprawnień), jeśli zaczyna się od /.
Bruno Bronosky
2
@JanVlcinsky ważne jest, aby wiedzieć, co jest i [co ważniejsze] nie jest zawarte w różnych formatach dystrybucji. Mam projekt publiczny, który rozpowszechniam tylko za pośrednictwem dystrybucji źródłowej, ponieważ dołączam plik boto.sample.cfg (który zawiera fałszywe dane uwierzytelniające AWS IAM) poza pakietem (w katalogu głównym), a dystrybucje binarne go nie będą zawierać. Tworzę prywatne kompilacje binarne do wdrożenia w środowisku produkcyjnym, które mają data_files = [('/ etc /', ['boto.cfg'])]. Jeśli chcesz rozprowadzać pliki inne niż py, musisz wiedzieć, jak to działa.
Bruno Bronosky
2
@MichaelGoerz Szczerze mówiąc, nie powinni. Ta odpowiedź jest starożytna, a sugerowanie też pbrjest złym pomysłem.
Arne
1
@ Zgadzam się, sprawy potoczyły się dalej. Obecnie konwertuję większość moich projektów z pbr na poezję
Jan Vlcinsky
7

Stare pytanie, nowa odpowiedź:

Nie, nie potrzebujesz MANIFEST.in. Aby jednak setuptoolszrobić to, co (zwykle) masz na myśli, musisz użyć funkcji setuptools_scm, która odgrywa rolę MANIFEST.inw 2 kluczowych miejscach:

  • Zapewnia, że ​​wszystkie istotne pliki są spakowane podczas uruchamiania sdistpolecenia (gdzie wszystkie odpowiednie pliki są zdefiniowane jako „wszystkie pliki pod kontrolą źródła”)
  • W przypadku używania include_package_datado dołączania danych pakietu jako części buildlub bdist_wheel. (ponownie: pliki pod kontrolą źródła)

Historyczne rozumienie MANIFEST.injest następujące: kiedy nie masz systemu kontroli wersji, potrzebujesz innego mechanizmu do rozróżnienia między „plikami źródłowymi” a „plikami, które znajdują się w katalogu roboczym”. Jednak Twój projekt jest pod kontrolą źródła (prawda ??), więc nie ma takiej potrzeby MANIFEST.in. Więcej informacji w tym artykule .

Klaas van Schelven
źródło