guix-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Should python-build-system packages have native-inputs?


From: Fis Trivial
Subject: Re: Should python-build-system packages have native-inputs?
Date: Sat, 28 Apr 2018 07:48:56 +0000

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 via email to

[Prev in Thread] Current Thread [Next in Thread]