On 20-07-2022 10:33, Hartmut Goebel wrote:
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.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?
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