From mboxrd@z Thu Jan 1 00:00:00 1970 From: Chris Marusich Subject: Re: Should python-build-system packages have native-inputs? Date: Sat, 28 Apr 2018 03:11:14 -0700 Message-ID: <87muxn63p9.fsf@gmail.com> References: <874ljv7rk0.fsf@gmail.com> <9766df40-5e91-577e-d2ed-195a1d8569fd@crazy-compilers.com> Mime-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:37498) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fCMp9-0007L1-IL for guix-devel@gnu.org; Sat, 28 Apr 2018 06:11:24 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1fCMp8-0000o9-50 for guix-devel@gnu.org; Sat, 28 Apr 2018 06:11:23 -0400 Received: from mail-pg0-x232.google.com ([2607:f8b0:400e:c05::232]:44400) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1fCMp7-0000ny-Sp for guix-devel@gnu.org; Sat, 28 Apr 2018 06:11:22 -0400 Received: by mail-pg0-x232.google.com with SMTP id 82-v6so3251589pge.11 for ; Sat, 28 Apr 2018 03:11:21 -0700 (PDT) In-Reply-To: <9766df40-5e91-577e-d2ed-195a1d8569fd@crazy-compilers.com> (Hartmut Goebel's message of "Sat, 28 Apr 2018 11:01:20 +0200") List-Id: "Development of GNU Guix and the GNU System distribution." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-devel-bounces+gcggd-guix-devel=m.gmane.org@gnu.org Sender: "Guix-devel" To: Hartmut Goebel , Fis Trivial Cc: guix-devel@gnu.org --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Fis and Hartmut, Thank you for the quick response! Hartmut Goebel writes: > As Fis already wrote:=C2=A0 These native-inputs are for testing and shoul= dn'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}.=C2=A0 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=C5=8Dan. 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. =2D-=20 Chris --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEy/WXVcvn5+/vGD+x3UCaFdgiRp0FAlrkSMIACgkQ3UCaFdgi Rp1tMg/8DJ/8rgvLLHuLwdbsXMMwRZxfenT0BhdZWXeWatw0L04yRJYBt7dWTXyy sVs9sgZ97ijoJDAU4nsNl24XxmkD/4QGDWuxfIgnFzLXxxsrQ9wJZzbFAeYBjA2w /wJAg4iILYKBl7U1Q9yQ+bXw+RS4Iqh0T3MiP1isY1xydfrwAwl5A3zRpF4wqiKc Je+58jj/UrJ8CqiVcoCD162EVKEsgzO5RRZ7UfzrYUTRgk4qUGJo6gjajEnQ7wtj ZymMRAHtsNDJ30KjDKtC9UxrzDYhOIJ2Z+wfuvd6TO7AreWq6ZvpiyM5+lEcQznU vzoNgYHgTdx51uywnint7+ymHmGwjwDU5yBOBemdzniXgav+A+8A+atkaofVh1HJ mX73mXzi2HyzChYwE5xL8W+xSA80vhafq3P3XzmTE8j3Uh8IB19tJSy0vY5Ipmcw hQ9zvewswzWpFrOgTT9LfL8BMgEFYz43xcY9xX5zOdVlZpDr2gXDdWB+P3SojYER ivq47uWWykz+o3AO0j7vDO/iKmzfpu2+s6mNN35GVBGQSP8skkTdp1DwyEyupveB 9fQBdznLdGd4ora8fpHr8NPhau0U4dqvcZ0g77ibsw7ndu8ul9Uu2KVlC9p44yRK KRQh2sUehPmpwJu62HJWb81qMCqMDgveC+O+86YAqmN/vhuU3ns= =SqAA -----END PGP SIGNATURE----- --=-=-=--