Re: Should python-build-system packages have native-inputs?

[Chris Marusich]

Hi Fis and Hartmut,

Thank you for the quick response!

Hartmut Goebel <address@hidden> writes:

> As Fis already wrote:  These native-inputs are for testing and shouldn't
> be installed in normal case.

It's true that for some of the packages that use the
python-build-system, we have been putting the dependencies required for
testing (such as python-pytest) into the package's native-inputs.
However, whether such dependencies are inputs or native-inputs does not
matter.  Because the python-build-system never cross-compiles, all of
the inputs, propagated-inputs, and native-inputs will be included in the
single list that gets passed to each of the build phases via the
#:inputs keyword argument.  You can verify this yourself by inserting
debug statements in the build phases.

In other words, it doesn't matter if we put python-pytest in a package's
inputs or its native-inputs.  The end result is the same.  If the
python-build-system actually did support cross-compilation, then this
might be a different story.  However, the python-build-system doesn't
cross-compile.  As a result, native-inputs and inputs are treated the
same in all of the phases defined in guix/build/python-build-system.scm.

> Please see "Python Modules" in the manual:
>
> Python packages required only at build time---e.g., those listed with
> the @code{setup_requires} keyword in @file{setup.py}---or only for
> testing---e.g., those in @code{tests_require}---go into
> @code{native-inputs}.  The rationale is that (1) they do not need to be
> propagated because they are not needed at run time, and (2) in a
> cross-compilation context, it's the ``native'' input that we'd want.

Thank you for mentioning the manual; I had forgotten that we include
explicit guidance for Python modules.  I've just reviewed the "Python
Modules" section.  I think we should not be advising people to use
native-inputs in packages that use the python-build-system.  There is no
meaningful difference between "native-inputs" and "inputs" in this case,
so asking people to contemplate the difference is like asking them a
kōan.  It's just going to cause confusion.

This is confusing.  And that is precisely why I think we should stop
declaring native-inputs for packages that use the python-build-system.
My understanding is that the concept of "native-inputs" for a package
only makes sense when that package uses a build system that can
cross-compile, such as the gnu-build-system.  Because the
python-build-system never cross-compiles, it doesn't make sense to
declare native-inputs for a package that uses the python-build-system.
Instead, those dependencies should just be declared as inputs.

>> * Are there any circumstances under which it actually WOULD make sense
>>   to cross-compile a Python package?
>
> Of course: Pure-python packages should be able to be cross-compiled
> without any problems, sicne the bytes-code is the same for all
> platforms.

I'm not sure that's the same thing as cross compilation.  When cross
compiling a program for a different architecture, the output of the
build is different for each architecture.  If Python's bytecode is the
same for all platforms, then it sounds like no cross-compilation is
necessary, which suggests that the notion of "cross compilation" does
not make sense for Python code.  Did I misinterpret what you meant?

> And for extension modules it would allow compiling on a faster
> environment (e.g. x86 vs. ARMv4).
>
> (I was not aware of python packages are not cross-compiled, thus I can
> only guess the reason why this is not possible: Python distutils may not
> be able to *cross*-compile extension modules. Maybe we could work on this.)

I am curious about extension modules.  I understand they are tied
closely to the underlying architecture, but I have little experience
with them, so I'm not sure how they relate to cross compilation.  In any
case, it doesn't change the fact that today, the python-build-system
does not cross-compile.

-- 
Chris

signature.asc
Description: PGP signature