Re: Guix-devel Digest, Vol 109, Issue 56

Re: Guix-devel Digest, Vol 109, Issue 56

[kiasoc5]

Date: Thu, 21 Jul 2022 18:34:58 +0200
From: zimoun <zimon.toutoune@gmail.com>
To: Hartmut Goebel <h.goebel@crazy-compilers.com>,
Guix-devel <guix-devel@gnu.org>
Subject: Re: native-inputs: Go for completeness or minimalism?
Message-ID: <86o7xi4e6l.fsf@gmail.com>
Content-Type: text/plain; charset=utf-8
 
Hi simon,

> 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.
> 

We could have packages recommend other packages to make this discovery
easier for users, like Arch's opt-depends.

> Cheers,
> simon

Re: Guix-devel Digest, Vol 109, Issue 56

[Maxime Devos]

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


On 22-07-2022 19:12, kiasoc5 wrote:
> We could have packages recommend other packages to make this discovery
> easier for users, like Arch's opt-depends.

This sounds like my previous proposal to me:

> 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. 
except it has a more precise semantics than Arch's, or did you have 
something different in mind?

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: Guix-devel Digest, Vol 109, Issue 56

[kiasoc5]

On Fri, Jul 22 2022, 07:16:59 PM +0200
Maxime Devos <maximedevos@telenet.be> wrote:

> On 22-07-2022 19:12, kiasoc5 wrote:
> > We could have packages recommend other packages to make this
> > discovery easier for users, like Arch's opt-depends.  
> 
> This sounds like my previous proposal to me:
> 
> > 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.   
> except it has a more precise semantics than Arch's, or did you have 
> something different in mind?

To me as a user, "guix shell -D package" means "install everything to
/build/ the package" and "guix shell package" means "install everything
to /use/ the package". We could make it even more granular:

1. Minimal dependencies for build time (native-inputs)
2. Maximal dependencies for build time (development-inputs)
3. Minimal dependencies for runtime (inputs + propagated-inputs)
4. Maximal dependencies for runtime (optdepends)

Deciding what is minimal/maximal is the issue. For instance should we
build manpages, which might pull in more dependencies (Crux omits them)?
Should we compile with every optional flag enabled, which also
might pull in more dependencies (like Arch)? Perhaps a policy or
standard would be helpful to decide how much we need, if we need more
levels of distinction.

Re: Guix-devel Digest, Vol 109, Issue 56

[Liliana Marie Prikler]

Hi,

Am Samstag, dem 23.07.2022 um 22:52 +0000 schrieb kiasoc5:
> On Fri, Jul 22 2022, 07:16:59 PM +0200
> Maxime Devos <maximedevos@telenet.be> wrote:
> 
> > On 22-07-2022 19:12, kiasoc5 wrote:
> > > We could have packages recommend other packages to make this
> > > discovery easier for users, like Arch's opt-depends.  
> > 
> > This sounds like my previous proposal to me:
> > 
> > > 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.   
> > except it has a more precise semantics than Arch's, or did you have
> > something different in mind?
> 
> To me as a user, "guix shell -D package" means "install everything to
> /build/ the package" and "guix shell package" means "install
> everything to /use/ the package". We could make it even more
> granular:
> 
> 1. Minimal dependencies for build time (native-inputs)
> 2. Maximal dependencies for build time (development-inputs)
> 3. Minimal dependencies for runtime (inputs + propagated-inputs)
> 4. Maximal dependencies for runtime (optdepends)
> 
> Deciding what is minimal/maximal is the issue. For instance should we
> build manpages, which might pull in more dependencies (Crux omits
> them)?
> Should we compile with every optional flag enabled, which also
> might pull in more dependencies (like Arch)? Perhaps a policy or
> standard would be helpful to decide how much we need, if we need more
> levels of distinction.
Minimal vs. maximal "runtime" dependencies are not really an issue in
Guix.  If anything, you splinter off a -minimal variant if a) it
suffices for building dependant packages or b) it's required for
bootstrapping.

For "build" time, the usual policy is to include everything used in the
actual build to the extent possible (for example, if an optional set of
tests requires a hard to bootstrap package, it is fine to skip those,
but ideally that should be noted).  Also, you need both native-inputs
and inputs at build time.

Now, the issue with development-inputs is two-fold.  First, it assumes
that native-inputs + inputs always suffice for building the package,
but that ignores the fact that we're sometimes using bootstrapped
autotools or similar which don't exist if you develop from git.  This
is already mentioned elsewhere as an issue that ought to be tackled by
"always" bootstrapping autotools etc., thus exercising the full build.

Second – the debate of this topic – is that development-inputs does not
include all the inputs a developer might actually want, e.g. linters
and formatters that don't run at build time, but you might nonetheless
use through some special command while developing the package.  To this
I want to pose a simple question: Many packages include
internationalization in their repositories, and a developer might want
to also act as translator (particularly if English is not their native
language).  Should we therefore include each and every po-file editor
in development inputs?  My personal opinion is that that'd be silly and
the developer is better served by making their own decisions as to
which tools to invoke.  There might perhaps be a statement made in the
case of particular build systems that encode these "developer inputs",
but I for one question this practice.

Cheers

Re: Guix-devel Digest, Vol 109, Issue 56

[zimoun]

Hi,

I am late to the party. :-)

On Fri, 22 Jul 2022 at 17:12, kiasoc5 <kiasoc5@disroot.org> wrote:

> We could have packages recommend other packages to make this discovery
> easier for users, like Arch's opt-depends.

From my point of view, ’recommend’ is like ’tag’.  It is not
well-defined and then it opens to many bikesheds.  And it adds
maintenance burden.

For instance, let consider the package hello written in C language.
Some people would recommend GDB, some Valgrind.  For packages using Git,
some would recommend plain Git, some git-extensions or Magit.  For
packages using Python, some would recommend plain Python and others
IPython, maybe Jupyter.  About COq, some would recommend Coq-IDE, some
Proof-General.  And so on.

From my opinion, the package manager is not the correct level for
“social” recommendations.


Cheers,
simon