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.