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

22.4.7 Модули Python

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

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

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

Примечание: Currently there are two different build systems for Python packages in Guix: python-build-system and pyproject-build-system. For the longest time, Python packages were built from an informally specified setup.py file. That worked amazingly well, considering Python’s success, but was difficult to build tooling around. As a result, a host of alternative build systems emerged and the community eventually settled on a formal standard for specifying build requirements. pyproject-build-system is Guix’s implementation of this standard. It is considered “experimental” in that it does not yet support all the various PEP-517 build backends, but you are encouraged to try it for new Python packages and report any problems. It will eventually be deprecated and merged into python-build-system.

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

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

Dependency information for Python packages is usually available in the package source tree, with varying degrees of accuracy: in the pyproject.toml file, the setup.py file, in requirements.txt, or in tox.ini (the latter mostly for test dependencies).

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

We currently package Python with setuptools and pip installed per default. This is about to change, and users are encouraged to use python-toolchain if they want a build environment for Python.
guix lint will warn if setuptools or pip are added as native-inputs because they are generally not necessary.
Зависимости Python, необходимые во время работы, идут в propagated-inputs. Они обычно определены с ключевым словом install_requires в setup.py или в файле requirements.txt.
Python packages required only at build time—e.g., those listed under build-system.requires in pyproject.toml or with the setup_requires keyword in setup.py—or dependencies only for testing—e.g., those in tests_require or tox.ini—go into native-inputs. The rationale is that (1) they do not need to be propagated because they are not needed at run time, and (2) in a cross-compilation context, it’s the “native” input that we’d want.
Примерами являются фреймворки тестирования pytest, mock и nose. Конечно, если какой-либо из этих пакетов также необходим во время запуска и работы, его следует указывать в propagated-inputs.
Всё, что не попало в предыдущие категории, указывается в inputs, например, программы или библиотеки C, необходимые для сборки пакетов Python, которые используют расширения C.
Если у пакета Python есть необязательные зависимости (extras_require), самостоятельно решите, нужно ли их добавлять в зависимости от их полезности или избыточности (see guix size).