Re: [PATCH] doc: Add guide how to specify dependencies for Python packages

[Hartmut Goebel]

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

-- 
Regards
Hartmut Goebel

| Hartmut Goebel  | h.goe...@crazy-compilers.com   |
| www.crazy-compilers.com | compilers which you thought are impossible |

Re: [PATCH] doc: Add guide how to specify dependencies for Python packages

[Ludovic Courtès]

Hartmut Goebel  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’.

Re: [PATCH] doc: Add guide how to specify dependencies for Python packages

[Hartmut Goebel]

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
.

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.

-- 
Regards
Hartmut Goebel

| Hartmut Goebel  | h.goe...@crazy-compilers.com   |
| www.crazy-compilers.com | compilers which you thought are impossible |