[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH] doc: Add guide how to specify dependencies for Python packag
From: |
Ludovic Courtès |
Subject: |
Re: [PATCH] doc: Add guide how to specify dependencies for Python packages |
Date: |
Thu, 06 Oct 2016 23:02:29 +0200 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/25.1 (gnu/linux) |
Hartmut Goebel <address@hidden> skribis:
> * doc/guix.texi (Python Modules): New sub-subsection "Specifying
> Dependencies".
Cool, thanks for working on it.
> address@hidden Specifying Dependencies
> address@hidden inputs, for Python packages
> +
> address@hidden
Could you add a sentence or two before @itemize to give some context?
> address@hidden
> +All Python package required at run-time need to go into
s/All Python package/Python packages/
s/run-time/run time/
> address@hidden These are typically defined in
^
(@pxref{package Reference, @code{propagated-inputs}})
> address@hidden or in a requirements-file.
Perhaps this is obvious to a seasoned Python programmer, but I think
we should clarify this:
in the @code{install_requires} field of whatever(?), or in a
@file{requirements.txt} file.
> address@hidden
> +Python packages required only for building (to be found e.g. in
> address@hidden) or testing (to be found e.g. in
Remove “e.g.” here or put it at the beginning of the parenthetical
expression.
> address@hidden) go into @code{native-inputs}. Examples are
> address@hidden, @emph{pytest}, @emph{mock}, and @emph{nose}. Of
> +course if any of these packages is required at run-time, it needs to be
> +set in @code{propagated-inputs}.
s/to be set in/to go to/
I’m not entirely convinced that this is an improvement of what “package
Reference” says. In particular, it describes ‘native-inputs’ as having
nothing to do with cross-compilation. OTOH, it has the advantage of
providing concrete instructions to someone focusing on Python.
Thoughts?
> address@hidden
> address@hidden only contain programs or C-libraries (and such) required
> +for building Python packages containing c-extensions (or such).
“C libraries” and “C extensions”; remove “(and/or such)”.
> address@hidden
> +If a Python package has optional extra dependencies
s/extra//
> +(@code{extras_require}), not these are not listed here at all - except
^^^ ^^^
Remove “not”.
“at all---except”
> +if there is a test-case in which case they are added to
> address@hidden
“test case”
I’m not sure what “if there is a test case” means here; should it be “if
it is a test suite framework”?
> +
> address@hidden
> +If a packages has complicated optional extra dependencies you may want
^
> +to define another package to ease resolving these dependencies for the
> +user. E.g. @code{python-abcdef-ssh} inherits @code{python-abcdef} and
> +adds the dependencies required for the @emph{ssh} extra feature.
The question of optional dependencies in general is already covered in
“Submitting Patches”, item 5.
Could you send an updated patch?
Thanks,
Ludo’.