unofficial mirror of guix-devel@gnu.org 
 help / color / mirror / code / Atom feed
* Re: Guix-devel Digest, Vol 109, Issue 56
       [not found] <mailman.5750.1658421830.1145.guix-devel@gnu.org>
@ 2022-07-22 17:12 ` kiasoc5
  2022-07-22 17:16   ` Maxime Devos
  0 siblings, 1 reply; 4+ messages in thread
From: kiasoc5 @ 2022-07-22 17:12 UTC (permalink / raw)
  To: guix-devel, zimon.toutoune, h.goebel

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


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

* Re: Guix-devel Digest, Vol 109, Issue 56
  2022-07-22 17:12 ` Guix-devel Digest, Vol 109, Issue 56 kiasoc5
@ 2022-07-22 17:16   ` Maxime Devos
  2022-07-23 22:52     ` kiasoc5
  0 siblings, 1 reply; 4+ messages in thread
From: Maxime Devos @ 2022-07-22 17:16 UTC (permalink / raw)
  To: kiasoc5, guix-devel, zimon.toutoune, h.goebel


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

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

* Re: Guix-devel Digest, Vol 109, Issue 56
  2022-07-22 17:16   ` Maxime Devos
@ 2022-07-23 22:52     ` kiasoc5
  2022-07-24  6:30       ` Liliana Marie Prikler
  0 siblings, 1 reply; 4+ messages in thread
From: kiasoc5 @ 2022-07-23 22:52 UTC (permalink / raw)
  To: Maxime Devos; +Cc: guix-devel

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.


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

* Re: Guix-devel Digest, Vol 109, Issue 56
  2022-07-23 22:52     ` kiasoc5
@ 2022-07-24  6:30       ` Liliana Marie Prikler
  0 siblings, 0 replies; 4+ messages in thread
From: Liliana Marie Prikler @ 2022-07-24  6:30 UTC (permalink / raw)
  To: kiasoc5, Maxime Devos; +Cc: guix-devel

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


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

end of thread, other threads:[~2022-07-24  6:32 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
     [not found] <mailman.5750.1658421830.1145.guix-devel@gnu.org>
2022-07-22 17:12 ` Guix-devel Digest, Vol 109, Issue 56 kiasoc5
2022-07-22 17:16   ` Maxime Devos
2022-07-23 22:52     ` kiasoc5
2022-07-24  6:30       ` Liliana Marie Prikler

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