Re: native-inputs: Go for completeness or minimalism?

[Maxime Devos]

On 20-07-2022 10:33, Hartmut Goebel wrote:
> Hi,
>
> shall native-inputs be as complete as possible or as minimal as possible?
>
> Background: I just stepped over a couple of packages where upstream 
> requires a lot of code-quality checkers which are not actually run 
> when running the tests. (More specific: These are Python packages 
> demanding tools like flake8, flake8-docstring, black, bandit.)
> Now when going for minimal dependencies and minimal native-inputs,
>
> Pro: Less dependencies, simpler dependency tree, thus less 
> computation, faster, less power consumption.
>
> Con: Might need phase to remove dependencies, 'guix shell -D' will not 
> provide every development requirement.
>
> Personally I tend to minimal.
>
> WDYT? 
I would go for only the dependencies actually used in the build process 
(including the test process), for less dependencies (we don't include, 
say, 'git' for every package that has a Git repo, only if the package 
actually uses Git in some fashion). For the "guix shell -D" for 
developing on the software, a "guix.scm" or "manifest.scm" can be 
written and included in the source code repo that contains the extra 
dependencies, though I have no idea what percentage of upstreams would 
actually include those.

Alternatively, packages could have an additional set of inputs 
(development-inputs?) for this use case, only added for "guix shell -D" 
and "guix environment", though then the build environment and "guix 
shell -D the-package" would diverge further.

Greetings,
Maxime.

OpenPGP_0x49E3EE22191725EE.asc
Description: OpenPGP public key

OpenPGP_signature
Description: OpenPGP digital signature