unofficial mirror of guix-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Maxime Devos <maximedevos@telenet.be>
To: Hartmut Goebel <h.goebel@crazy-compilers.com>,
	Guix-devel <guix-devel@gnu.org>
Subject: Re: native-inputs: Go for completeness or minimalism?
Date: Wed, 20 Jul 2022 11:03:51 +0200	[thread overview]
Message-ID: <73f6410f-860c-34d1-043b-5c9aed619fe9@telenet.be> (raw)
In-Reply-To: <54cc479c-8c7b-5161-0666-26ef199ef8b0@crazy-compilers.com>


[-- Attachment #1.1.1: Type: text/plain, Size: 1572 bytes --]


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.


[-- Attachment #1.1.2: OpenPGP public key --]
[-- Type: application/pgp-keys, Size: 929 bytes --]

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 236 bytes --]

  reply	other threads:[~2022-07-20  9:13 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-07-20  8:33 native-inputs: Go for completeness or minimalism? Hartmut Goebel
2022-07-20  9:03 ` Maxime Devos [this message]
2022-07-21 16:34 ` zimoun

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://guix.gnu.org/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=73f6410f-860c-34d1-043b-5c9aed619fe9@telenet.be \
    --to=maximedevos@telenet.be \
    --cc=guix-devel@gnu.org \
    --cc=h.goebel@crazy-compilers.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/guix.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).