Danny Milosavljevic <dan...@scratchpost.org> writes: > Hi, > > On Mon, 28 Nov 2016 17:08:49 -0800 > Maxim Cournoyer <maxim.courno...@gmail.com> wrote: > >> (inputs >> - `(("python-setuptools" ,python-setuptools) >> - ("python-virtualenv" ,python-virtualenv) >> - ;; Tests >> - ("python-mock" ,python-mock) >> - ("python-pytest" ,python-pytest) >> - ("python-scripttest" ,python-scripttest))) >> + `(("python-setuptools" ,python-setuptools) >> + ;; Tests requirements. >> + ("python-mock" ,python-mock) >> + ("python-pretend" ,python-pretend) >> + ("python-pytest" ,python-pytest) >> + ("python-scripttest" ,python-scripttest) >> + ("python-virtualenv" ,python-virtualenv))) > > Why are the test requirements regular inputs? If they aren't required at > runtime, they should be native-inputs.
Hi Danny, and sorry for my delayed answer. I was under the impression that native-inputs only had meaning when cross-compiling and that otherwise they were the same. From the guix manual, section 5.1.1, it says: The distinction between ‘native-inputs’ and ‘inputs’ is necessary when considering cross-compilation. When cross-compiling, dependencies listed in ‘inputs’ are built for the _target_ architecture; conversely, dependencies listed in ‘native-inputs’ are built for the architecture of the _build_ machine. But then at section 7.6.5.1 it also says: Python packages required only at build time—e.g., those listed with the ‘setup_requires’ keyword in ‘setup.py’—or only for testing—e.g., those in ‘tests_require’—go into ‘native-inputs’. The rationale is that (1) they do not need to be propagated because they are not needed at run time, and (2) in a cross-compilation context, it’s the “native” input that we’d want. I stand corrected, thanks! I'll rework the pip package definition and send a patch later this week, also taking into account the latest changes to the python build system from Hartmut. Maxim