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 |
