我们目前为Python 2和Python 3打包，如版本号的规则所述，它们的Scheme变量名分别是
Some modules are compatible with only one version of Python, others with
both. If the package Foo is compiled with Python 3, we name it
python-foo. If it is compiled with Python 2, we name it
python2-foo. Packages should be added when they are necessary; we
don’t add Python 2 variants of the package unless we are going to use them.
注: 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.
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).
pipinstalled per default. This is about to change, and users are encouraged to use
python-toolchainif they want a build environment for Python.
guix lint will warn if
pip are added
as native-inputs because they are generally not necessary.
build-system.requiresin pyproject.toml or with the
setup_requireskeyword in setup.py—or dependencies only for testing—e.g., those in
tests_requireor 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.