unofficial mirror of guix-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Fis Trivial <ybbs.daans@hotmail.com>
To: Chris Marusich <cmmarusich@gmail.com>
Cc: "guix-devel@gnu.org" <guix-devel@gnu.org>
Subject: Re: Should python-build-system packages have native-inputs?
Date: Sat, 28 Apr 2018 07:48:56 +0000	[thread overview]
Message-ID: <BLUPR16MB050044BA9BDF1E61344CF106928C0@BLUPR16MB0500.namprd16.prod.outlook.com> (raw)
In-Reply-To: <874ljv7rk0.fsf@gmail.com>


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-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)))))
> --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.

  reply	other threads:[~2018-04-28  7:49 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-04-28  6:50 Should python-build-system packages have native-inputs? Chris Marusich
2018-04-28  7:48 ` Fis Trivial [this message]
2018-04-29 17:07   ` Mark H Weaver
2018-04-28  9:01 ` Hartmut Goebel
2018-04-28 10:11   ` Chris Marusich
2018-04-28 11:25     ` Hartmut Goebel
2018-04-28 19:22       ` Chris Marusich
2018-04-29 17:11       ` Mark H Weaver

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://guix.gnu.org/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=BLUPR16MB050044BA9BDF1E61344CF106928C0@BLUPR16MB0500.namprd16.prod.outlook.com \
    --to=ybbs.daans@hotmail.com \
    --cc=cmmarusich@gmail.com \
    --cc=guix-devel@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/guix.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).