diff mbox

doc: Add guide how to specify dependencies for Python packages

Message ID 1475571630-27701-1-git-send-email-h.goebel@crazy-compilers.com
State New
Headers show

Commit Message

Hartmut Goebel Oct. 4, 2016, 9 a.m. UTC
* doc/guix.texi (Python Modules): New sub-subsection "Specifying
  Dependencies".
---
 doc/guix.texi | 37 +++++++++++++++++++++++++++++++++++++
 1 file changed, 37 insertions(+)

Comments

Hartmut Goebel Oct. 4, 2016, 9:06 a.m. UTC | #1
Am 04.10.2016 um 11:00 schrieb Hartmut Goebel:
> * doc/guix.texi (Python Modules): New sub-subsection "Specifying
>   Dependencies".

FYI: This documents what we discussed in
<http://lists.gnu.org/archive/html/guix-devel/2016-09/msg01450.html>.

I'll add a section about dependencies for Python applications in a later
patch. I first want to finish the work on the new python-build-system.
Ludovic Courtès Oct. 6, 2016, 9:02 p.m. UTC | #2
Hartmut Goebel <h.goebel@crazy-compilers.com> skribis:

> * doc/guix.texi (Python Modules): New sub-subsection "Specifying
>   Dependencies".

Cool, thanks for working on it.

> +@subsubsection Specifying Dependencies
> +@cindex inputs, for Python packages
> +
> +@itemize

Could you add a sentence or two before @itemize to give some context?

> +@item
> +All Python package required at run-time need to go into

s/All Python package/Python packages/
s/run-time/run time/

> +@code{propagated-inputs}.  These are typically defined in
                           ^
(@pxref{package Reference, @code{propagated-inputs}})

> +@code{install_requires} 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.

> +@item
> +Python packages required only for building (to be found e.g. in
> +@code{setup_requires}) or testing (to be found e.g. in

Remove “e.g.” here or put it at the beginning of the parenthetical
expression.

> +@code{tests_require}) go into @code{native-inputs}. Examples are
> +@emph{setuptools}, @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?

> +@item
> +@code{inputs} 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)”.

> +@item
> +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
> +@code{native-inputs}.

“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”?

> +
> +@item
> +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’.
Hartmut Goebel Oct. 7, 2016, 7:44 a.m. UTC | #3
Hi Ludo,


thanks for the review and for proof-reading :-)

I'll send an updated patch in a few days, waiting for some more feedback
on this:


Am 06.10.2016 um 23:02 schrieb Ludovic Courtès:
>
>> +@code{tests_require}) go into @code{native-inputs}. Examples are
>> +@emph{setuptools}, @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}.
> 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?

My aim was to provide concrete instructions for those wanting to package
Python packages. But I will think about how to add some pointer to
cross-compilation.

From a Python programmers perspective, "cross-compilation" is a
non-issue in most cases. Most Python packages are pure Python, will be
compiled into byte-code and thus they are platform independent. (Much
like .jar files) This is why most python packages are marked as "noarch"
in other Linux distributions. As a Python programmer I think in terms of
build-time, maybe test-time and run-time.

This only exception for this are Python packages containing C-code
(called "extension modules")*.* But I have to admit that I have no clue
about cross-compiler these. (I do no even find good introductions on
this in the web.)

The official Python packaging guide [1] does not really talk about
cross-compilation. Only about "Cross-compiling on Windows".

[1] https://docs.python.org/3/distutils/builtdist.html
diff mbox

Patch

diff --git a/doc/guix.texi b/doc/guix.texi
index 9bd8b43..f51ab75 100644
--- a/doc/guix.texi
+++ b/doc/guix.texi
@@ -12194,6 +12194,43 @@  starts with @code{py} (e.g. @code{pytz}), we keep it and prefix it as
 described above.
 
 
+@subsubsection Specifying Dependencies
+@cindex inputs, for Python packages
+
+@itemize
+
+@item
+All Python package required at run-time need to go into
+@code{propagated-inputs}.  These are typically defined in
+@code{install_requires} or in a requirements-file.
+
+@item
+Python packages required only for building (to be found e.g. in
+@code{setup_requires}) or testing (to be found e.g. in
+@code{tests_require}) go into @code{native-inputs}. Examples are
+@emph{setuptools}, @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}.
+
+@item
+@code{inputs} only contain programs or C-libraries (and such) required
+for building Python packages containing c-extensions (or such).
+
+@item
+If a Python package has optional extra dependencies
+(@code{extras_require}), not these are not listed here at all - except
+if there is a test-case in which case they are added to
+@code{native-inputs}.
+
+@item
+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.
+
+@end itemize
+
+
 @node Perl Modules
 @subsection Perl Modules