Модули Python (Руководство по GNU Guix)

22.8.8 Модули Python

В настоящее время мы поставляем пакеты Python 2 и Python 3 через переменную Scheme под именами python-2 и python в соответствии с Номера версий. Чтобы предотвратить путаницу и конфликты имён с другими языками программирования, желательно, чтобы имена пакетов с модулями Python содержали слово python.

Некоторые модули совместимы только с одной версией Python, другие - с обеими. Если пакет Foo скомпилирован с Python 3, мы называем его python-foo. Если он скомпилирован с Python 2, мы называем его python2-foo. Пакеты Python 2 удаляются из дистрибутива; пожалуйста, не присылайте новые пакеты Python 2.

Если проект уже содержит слово python, оно отбрасывается; например, модуль python-dateutil упаковывается под именем python-dateutil и python2-dateutil. Если имя проекта начинается с py (т.е. pytz), мы оставляем такое имя и добавляем префикс, как это описано выше.

Примечание: В настоящий момент в Guix существует две системы сборки для пакетов Python: python-build-system and pyproject-build-system. В течение долгого времени, пакеты Python собирались из файла setup.py file, для которого нет официальной спецификации. Это работало удивительно прекрасно, учитывая успех языка Python, но при такого подходе было тяжело построить инструментаж. В конечном итоге, появилось несколько альтернативных систем сборки, и сообщество в конце концов сошлось на формальном стандарте для описания требований сборки. Система pyproject-build-system является Guixовским воплощением этого стандарта. Она считается “экспериментальной” в том смысле, что ещё не поддерживает все из различных бэкендов сборки PEP-517, но мы поощряем её использование для новых пакетов Python, и просим сообщать об обнаруженных проблемах. Рано или поздно она будет упразднена и объединена в python-build-system.

Перечисление зависимостей

22.8.8.1 Перечисление зависимостей

Информация о зависимостях для пакетов Python обычно находится в исходном коде пакета, с различной степенью точности: в файлах pyproject.toml, setup.py, requirements.txt, и в файле tox.ini (в последнем указываются в основном зависимости для выполнения тестов).

При написании рецепта сборки пакета Python ваша задача — сопоставить эти зависимости к должному типу “input” (see inputs). Хотя импортёр pypi обычно отрабатывает хорошо (see Вызов guix import), желательно пройтись по приведённому чек-листу, чтобы узнать, какая зависимости куда уходит.

В настоящее время мы поставляем Python с setuptools и pip, установленными по умолчанию. Это скоро изменится, и пользователям рекомендуется использовать python-toolchain, если нужно окружение сборки для Python.
guix lint выдаст предупреждение, если setuptools или pip добавлены как native-inputs, поскольку они почти всегда не нужны.
Зависимости Python, необходимые во время работы, идут в propagated-inputs. Они обычно определяются ключевым словом install_requires в setup.py или в файле requirements.txt.
Пакеты Python, необходимые только во время сборки, например, перечисленные в build-system.requires файла pyproject.toml, или с ключевым словом setup_requires в setup.py, или же зависимости, необходимые только для тестирования, как, например, в setup_requires или tox.ini, указываются, как native-inputs. Резон этого в том, что, во-первых, их не нужно передавать в конечный пакет, потому что они не нужны для его нормальной работы, а во-вторых, в контексте кросс-компиляции они и есть "родные" входные данные, которые там нужны.
Примерами являются фреймворки тестирования pytest, mock и nose. Конечно, если какой-либо из этих пакетов также необходим во время запуска и работы, его следует указывать в propagated-inputs.
Всё, что не попало в предыдущие категории, указывается в inputs, например, программы или библиотеки C, необходимые для сборки пакетов, которые содержат расширения Python на C.
Если у пакета Python есть необязательные зависимости (extras_require), решайте самостоятельно, нужно ли их добавлять, судя по отношению их пользы к накладным расходам (see guix size).