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
