From mboxrd@z Thu Jan 1 00:00:00 1970 From: Fis Trivial Subject: Re: Should python-build-system packages have native-inputs? Date: Sat, 28 Apr 2018 07:48:56 +0000 Message-ID: References: <874ljv7rk0.fsf@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:47952) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fCKbP-00074G-TN for guix-devel@gnu.org; Sat, 28 Apr 2018 03:49:04 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1fCKbL-0002Df-0Q for guix-devel@gnu.org; Sat, 28 Apr 2018 03:49:03 -0400 Received: from mail-oln040092007099.outbound.protection.outlook.com ([40.92.7.99]:26797 helo=NAM03-CO1-obe.outbound.protection.outlook.com) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1fCKbK-0002DG-Lh for guix-devel@gnu.org; Sat, 28 Apr 2018 03:48:58 -0400 In-Reply-To: <874ljv7rk0.fsf@gmail.com> Content-Language: en-US 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: Chris Marusich Cc: "guix-devel@gnu.org" Chris Marusich writes: > 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: > > --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-compilat= ion > (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))= ))) > --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! I'm confused, some native-inputs are for testing. They shouldn't be installed in normal case.