unofficial mirror of guix-devel@gnu.org 
 help / color / mirror / code / Atom feed
* native-inputs: Go for completeness or minimalism?
@ 2022-07-20  8:33 Hartmut Goebel
  2022-07-20  9:03 ` Maxime Devos
  2022-07-21 16:34 ` zimoun
  0 siblings, 2 replies; 3+ messages in thread
From: Hartmut Goebel @ 2022-07-20  8:33 UTC (permalink / raw)
  To: Guix-devel

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?

-- 
Regards
Hartmut Goebel

| Hartmut Goebel          | h.goebel@crazy-compilers.com               |
| www.crazy-compilers.com | compilers which you thought are impossible |



^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: native-inputs: Go for completeness or minimalism?
  2022-07-20  8:33 native-inputs: Go for completeness or minimalism? Hartmut Goebel
@ 2022-07-20  9:03 ` Maxime Devos
  2022-07-21 16:34 ` zimoun
  1 sibling, 0 replies; 3+ messages in thread
From: Maxime Devos @ 2022-07-20  9:03 UTC (permalink / raw)
  To: Hartmut Goebel, Guix-devel


[-- 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 --]

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: native-inputs: Go for completeness or minimalism?
  2022-07-20  8:33 native-inputs: Go for completeness or minimalism? Hartmut Goebel
  2022-07-20  9:03 ` Maxime Devos
@ 2022-07-21 16:34 ` zimoun
  1 sibling, 0 replies; 3+ messages in thread
From: zimoun @ 2022-07-21 16:34 UTC (permalink / raw)
  To: Hartmut Goebel, Guix-devel

Hi Hartmut,

On Wed, 20 Jul 2022 at 10:33, Hartmut Goebel <h.goebel@crazy-compilers.com> wrote:

> Personally I tend to minimal.

Me too.  Being minimal is better on all aspects, IMHO.

The only drawback is indeed “guix shell -D”.  But, people developing can
add the missing or extra packages.  To me, Guix provides the minimal
environment for building and running one package.

Otherwise, we could imagine to create two packages.

However, there is no consensus about this “minimalism”.  For instance,
some packages have multi-outputs which implies that “guix shell -D” is
not minimal.


Cheers,
simon




^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2022-07-21 16:56 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-07-20  8:33 native-inputs: Go for completeness or minimalism? Hartmut Goebel
2022-07-20  9:03 ` Maxime Devos
2022-07-21 16:34 ` zimoun

Code repositories for project(s) associated with this 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).