We currently package Python 2 and Python 3, under the Scheme variable names
python as explained in Version Numbers.
To avoid confusion and naming clashes with other programming languages, it
seems desirable that the name of a package for a Python module contains
Some modules are compatible with only one version of Python, others with both.
If the package Foo compiles only with Python 3, we name it
python-foo; if it compiles only with Python 2, we name it
python2-foo. If it is compatible with both versions, we create two
packages with the corresponding names.
If a project already contains the word
python, we drop this;
for instance, the module python-dateutil is packaged under the names
python2-dateutil. If the project name
pytz), we keep it and prefix it as
Dependency information for Python packages is usually available in the package source tree, with varying degrees of accuracy: in the setup.py file, in requirements.txt, or in tox.ini.
Your mission, when writing a recipe for a Python package, is to map
these dependencies to the appropriate type of “input” (see inputs). Although the
pypi importer normally does a
good job (see Invoking guix import), you may want to check the
following check list to determine which dependency goes where.
pipinstalled like Python 3.4 has per default. Thus you don’t need to specify either of these as an input.
guix lintwill warn you if you do.
propagated-inputs. They are typically defined with the
install_requireskeyword in setup.py, or in the requirements.txt file.
setup_requireskeyword in setup.py—or only for testing—e.g., those in
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.
Examples are the
frameworks. Of course if any of these packages is also required at
run-time, it needs to go to
inputs, for example programs or C libraries required for building Python packages containing C extensions.
extras_require), it is up to you to decide whether to add them or not, based on their usefulness/overhead ratio (see