Hi Fis and Hartmut, Thank you for the quick response!
Hartmut Goebel <h.goe...@crazy-compilers.com> 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