native-inputs: Go for completeness or minimalism?

native-inputs: Go for completeness or minimalism?

[Hartmut Goebel]

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 |

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

[Maxime Devos]

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

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

[zimoun]

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