Чи потрібні проекти python на MANIFEST.in, і що має бути в ньому?

120

Посібник "Розповсюдження Python" (був на python-distribute.org, але ця реєстрація минула) говорить про те, щоб у файлі були виключені doc/txtфайли, а .pyфайли виключеніMANIFEST.in

Документація джерела повідомляє мені, що використовує лише sdist MANIFEST.inі включає лише вказані вами файли та .pyфайли. Він також говорить мені використовувати: python setup.py sdist --manifest-onlyдля створення MANIFEST, але python каже мені, що цього не існує

Я розумію, що це з різних версій python, і система дистрибуції перебуває в повному хаосі, але припускаючи, що я використовую python 3 та setuptools(нова, що включає в себе дистрибуцію, але тепер називається setuptools, а не старі setuptools, які були застарілими лише для інструментів розподілу щоб повернутись до розповсюдження та розповсюдження перейменованого на setuptools .....)

і я дотримуюся "стандартної" структури папки та setup.pyфайлу,

Чи потрібно мені MANIFEST.in?
Що має бути в ньому?
Коли всі ці різні пакетні системи та методи стануть єдиним простим процесом?

python setuptools

— Ніл Уокер
джерело

Відповіді:

117

Re: "Мені потрібен MANIFEST.in?

Ні, вам не доведеться користуватися MANIFEST.in. Обидва, distutilsі setuptoolsвключають у пакунок розповсюдження джерела всі файли, згадані в setup.py- модулі, файли python пакета README.txtта test/test*.py. Якщо це все, що ви хочете мати в дистрибутивному пакеті, вам не доведеться користуватися MANIFEST.in.

Якщо ви хочете маніпулювати (додавати або видаляти) файли за замовчуванням, які слід включити, вам доведеться скористатися MANIFEST.in.

Re: Що має бути в ньому?

Процедура проста:

Переконайтеся, що setup.pyви включаєте (за допомогою setupаргументів) усі файли, які вважаєтесь важливими для запуску програми (модулі, пакети, сценарії ...)
Уточнити, чи є деякі файли, які потрібно додати, або кілька файлів, які потрібно виключити. Якщо жоден з них не потрібен, тоді немає необхідності у використанні MANIFEST.in.
Якщо MANIFEST.inпотрібно, створіть його. Зазвичай ви додаєте туди tests*/*.pyфайли, README.rstякщо не використовуєте README.txt, docsфайли та, можливо, деякі файли даних для тестового набору, якщо це необхідно.

Наприклад:

include README.rst
include COPYING.txt

Щоб перевірити це, запустіть python setup.py sdistі вивчіть тарбол, створений під dist/.

Коли всі ці різні пакунки будуть ...

Порівнюючи ситуацію сьогодні та 2 роки тому - ситуація набагато краща - setuptoolsце шлях. Ви можете ігнорувати факт, distutilsтрохи зламаний і є базовим на низькому рівні, setuptoolsтому що setuptoolsпотрібно подбати про приховування цих речей від вас.

EDIT : Останні декілька проектів, які я використовую pbrдля побудови дистрибутивних пакетів з трьома лініями setup.pyта рештою, що знаходяться у setup.cfgта requirements.txt. Не потрібно дбати MANIFEST.inі про інші дивні речі. Навіть незважаючи на те, що пакет заслуговує на трохи більше документації. Див. Http://docs.openstack.org/developer/pbr/

— Ян Вльчинський
джерело

З мого обмеженого досвіду, здається, що якщо ви хочете включати файли не всередині модуля python (dir з init .py), ви повинні використовувати MANIFEST.in і використовувати команду sdist(означає: розподіл джерела ). Якщо врахувати , що bdistі bdist_wheelє двійковим і призначені тільки для установки в вашому пітона шляху, це має сенс. (Куди б пішли ці немодульні файли та каталоги? В /usr/local/lib/python2.7/dist-packages/? Безумовно, ні.) Але це варто згадати, оскільки це заплутано бачити створений архів і до них не включати файли.

— Бруно Броноський

Щоб запобігти неминучому package_dataта data_filesрекомендаціям, які виходять за рамки, я продовжу. package_dataсписок файлів, які встановлюються разом із вашим пакетом, до dist-packages/yourpackageякого було б пропущено, оскільки не має * .py імені. data_filesперелічує файли, які встановлюються поза пакетом. Кожен запис вказує цільовий шлях, який має префікс, sys.prefixякщо він відносний або створений безпосередньо (дозволи дозволяють), якщо він починається з а /.

— Бруно Броноський

@JanVlcinsky важливо знати, що є і [що важливіше] не включається в різні формати розповсюдження. У мене є публічний проект, який я розповсюджую лише через джерело розповсюдження, тому що я включаю файл boto.sample.cfg (який містить підроблений обліковий запис AWS IAM) поза пакетом (у корені), а двійкові дистрибутиви не включатимуть його. Я роблю приватні бінарні збірки для розгортання у виробництво, які мають data_files = [('/ etc /', ['boto.cfg'])]. Якщо ви хочете поширювати файли, які не стосуються py, ви повинні знати, як працюють ці речі.

— Бруно Броноський

@MichaelGoerz Чесно кажучи, вони не повинні. Ця відповідь давня, і припускати, що pbrце теж погана ідея.

— Арн

@Аме погоджуюся, справи йшли далі. В даний час я перетворюю більшість своїх проектів з pbr на поезію

— Ян Вльчинський,

Старе запитання, нова відповідь:

Ні, вам не потрібно MANIFEST.in. Однак, щоб setuptoolsзробити те, що ви (як правило) маєте на увазі, вам потрібно скористатися тим setuptools_scm, що виконує роль MANIFEST.inу двох ключових місцях:

Це забезпечує, що всі відповідні файли запаковані під час виконання sdistкоманди (де всі відповідні файли визначені як "усі файли під управлінням джерелом")
При використанні include_package_dataдля включення даних пакетів у складі buildабо bdist_wheel. (знову: файли під контролем джерела)

Історичне розуміння цього поняття MANIFEST.in: коли у вас немає системи управління джерелом, вам потрібен якийсь інший механізм, щоб розрізняти "вихідні файли" та "файли, які трапляються у вашому робочому каталозі". Однак ваш проект знаходиться під контролем джерела (правда ??), тому в цьому немає потреби MANIFEST.in. Більше інформації в цій статті .

— Клаас ван Шельвен
джерело