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.goebel@crazy-compilers.com               |
| www.crazy-compilers.com | compilers which you thought are impossible |