Нужен ли проектам на Python MANIFEST.in и что в нем должно быть?

120

В руководстве "Python Distribute" (было на python-distribute.org, но эта регистрация истекла) говорится, что нужно включать doc/txtфайлы, а .pyфайлы исключены из MANIFEST.inфайла

Документация sourcedist сообщает мне, что используется только 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- modules, package python files 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позаботится о том, чтобы скрыть эти вещи от вас.

РЕДАКТИРОВАТЬ : Последние несколько проектов, которые я использую 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являются двоичными и предназначены только для установки на вашем пути к Python, это имеет смысл. (Куда будут идти эти немодульные файлы и каталоги? В /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его тоже - плохая идея.

— Arne

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

— Ян Влцинский

Старый вопрос, новый ответ:

Нет, не надо MANIFEST.in. Однако, чтобы setuptoolsсделать то, что вы (обычно) имеете в виду, вам нужно использовать setuptools_scm, который играет роль MANIFEST.inв двух ключевых местах:

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

Историческое понимание MANIFEST.inтаково: когда у вас нет системы контроля версий, вам нужен какой-то другой механизм, чтобы различать «исходные файлы» и «файлы, которые случайно находятся в вашем рабочем каталоге». Однако ваш проект находится под контролем источника (верно ??), поэтому в нем нет необходимости MANIFEST.in. Больше информации в этой статье .

— Клаас ван Шелвен
источник