From mboxrd@z Thu Jan 1 00:00:00 1970 From: Chris Marusich Subject: Should python-build-system packages have native-inputs? Date: Fri, 27 Apr 2018 23:50:39 -0700 Message-ID: <874ljv7rk0.fsf@gmail.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]:40966) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fCJh1-0003BU-Rf for guix-devel@gnu.org; Sat, 28 Apr 2018 02:50:48 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1fCJh0-0004gr-SV for guix-devel@gnu.org; Sat, 28 Apr 2018 02:50:47 -0400 Received: from mail-pf0-x230.google.com ([2607:f8b0:400e:c00::230]:40383) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1fCJh0-0004gn-Li for guix-devel@gnu.org; Sat, 28 Apr 2018 02:50:46 -0400 Received: by mail-pf0-x230.google.com with SMTP id f189so3055706pfa.7 for ; Fri, 27 Apr 2018 23:50:46 -0700 (PDT) Received: from garuda.local ([2601:602:9d02:4725:6495:ba21:1ebe:620a]) by smtp.gmail.com with ESMTPSA id z15-v6sm4892689pgr.55.2018.04.27.23.50.43 for (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Fri, 27 Apr 2018 23:50:43 -0700 (PDT) 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: guix-devel@gnu.org --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Hi Guix, I've noticed that a fair number of packages in gnu/packages/python.scm using the python-build-system declare native-inputs. I suspect that in every case, these should actually just be inputs. I also suspect that this is benign, except perhaps for the fact that it may confuse Pythonistas who (like myself) initially started out by looking at these packages as examples of how to get started defining packages in Guix. The python-build-system's "lower" procedure (in guix/build-system/python.scm) explicitly forbids cross-compilation: =2D-8<---------------cut here---------------start------------->8--- (define* (lower name #:key source inputs native-inputs outputs system target (python (default-python)) #:allow-other-keys #:rest arguments) "Return a bag for NAME." (define private-keywords '(#:source #:target #:python #:inputs #:native-inputs)) (and (not target) ;XXX: no cross-compilation (bag (name name) (system system) (host-inputs `(,@(if source `(("source" ,source)) '()) ,@inputs ;; Keep the standard inputs of 'gnu-build-system'. ,@(standard-packages))) (build-inputs `(("python" ,python) ,@native-inputs)) (outputs outputs) (build python-build) (arguments (strip-keyword-arguments private-keywords arguments))))) =2D-8<---------------cut here---------------end--------------->8--- As for the native-inputs, they get stored in the bag's build-inputs, which eventually find their way to the "inputs" keyword argument used on the build side by the various build phases. In fact, the inputs, propagated-inputs, and native-inputs of any package that uses the python-build-system are all put into this "inputs" keyword argument. With this in mind, I have two questions: * Should we change these native-inputs to inputs to prevent confusion? I can personally vouch for the fact that the presence of native-inputs in python-build-system packages confused the heck out of me at first! * Are there any circumstances under which it actually WOULD make sense to cross-compile a Python package? For now, I think the answers to these questions are "sure" and "probably not", respectively. I'm very curious to hear your thoughts about the second question, in particular! =2D-=20 Chris --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEy/WXVcvn5+/vGD+x3UCaFdgiRp0FAlrkGb8ACgkQ3UCaFdgi Rp31fw/9H9+oMheghpFf1T0YOagrGbTrW654AM3GzH42mSBazhEIgSg+4HJP7PmZ Doal9wOfmPfss2orjRc5Qpe83/ooNyc6ugu12BRtKgFIW9v6uYoX4paccZsLRRnb SnpOasG19u0eLysLncxarITwkeHTuJeOKvbMjO8T/9zLnAU1LhvqstGw92KalBBy pkDBHgrUUTiFLeNzC/YvCoqxiVju2jkqOVxlkwvHwD3VDWoZpaUS8uOI7EUVtd0C t6PoXRPce1MBnOlUh8jQ9nP9LtpbzUP20cFV8pAxV+gL1zn5WxUpIgTtMPb9ecCh 09Wk3OE/U/z2Qr3CSveEErulaRCxClqxJzGeNfXuJpJZwhDjn6xats2FoC0PM653 eqvbPlieobjIzWSEsNvXI898zPkQwGPUNmNG4k2ESU3RyOioFALnJfYf0RdbTDz+ FEI10xkAlxUpeRLi0u6wMayijwxVL0N0Mcq4ZbvoX7t4wlwtrlD+YDccG147Idsu dc8rqHRfTFe6fVIExLnFOaw7gGbNEMCE5jJjOyS/udxcLP/t2Lg35rvv14p715Jc 4E96QPBO+SpksuJm997Ya8k0RJGpWEimFKNkrGXb8FcKGyDceYR7YrylnsApMNzy ztbDdhV1MsrmZWttlMb4tKk9PZieUP+P1wQFJqvSOa0JU+clJ8E= =ABW3 -----END PGP SIGNATURE----- --=-=-=--