我们目前为Python 2和Python 3打包，如版本号的规则所述，它们的Scheme变量名分别是python-2和python。为了避免和其他编程语言的冲突，Python模块的软件包名字最好含有python。
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. Python 2 packages are being removed from the
distribution; please do no not submit any new Python 2 packages.
如果一个项目的名字已经含有python这个单词，我们把它丢掉；例如，python-dateutil模块打包后的名字是python-dateutil和python2-dateutil。如果项目的名字以py开头（如
pytz），我们把它保留，并且添加上面所述的前缀。
注: 目前在 Guix 中有两种不同的 Python 包构建系统：python-build-system 和pyproject-build-system。 在很长的一段时间里，Python 包是从非正式指定的 setup.py 文件构建的。 考虑到 Python 的成功，这工作得非常好，但很难围绕它构建工具。 结果，出现了许多替代构建系统，社区最终确定了一个 正式标准 来指定构建要求。 pyproject-build-system 是 Guix 对该标准的实现。 它被认为是“实验性的”，因为它还不支持所有不同的 PEP-517 编译后端，但我们鼓励您为新的 Python 包尝试它并报告任何问题。 它最终将被弃用并合并到 python-build-system 中。
Python软件包的依赖信息通常在包的源代码树里，各种文件有不同的准确度：setup.py文件，requirements.txt文件，或在 tox.ini文件（后者主要用于测试依赖项）。
你在写软件包配方时的任务是把这些依赖转换成相应的“输入”（see inputs）。尽管pypi导入工具通常可以做得很好（see Invoking guix import），你可能想检查下面这个清单，以决定每个依赖放在哪儿。
setuptools 和 pip。 这即将改变，如果用户想要 Python
的构建环境，我们鼓励他们使用python-toolchain。
如果将 setuptools 或 pip 添加为本机输入，guix lint
将发出警告，因为通常它们不是必需的。
propagated-inputs。它们通常由setup.py文件里的install_requires关键字或requirements.txt文件定义。
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语言库。
extras_require），由你根据它们的性价比（用处/负担）决定是否添加它们（see guix size）。