guix-patches
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[bug#50620] [PATCH 1/2] guix: packages: Document 'computed-origin-method


From: Liliana Marie Prikler
Subject: [bug#50620] [PATCH 1/2] guix: packages: Document 'computed-origin-method'.
Date: Tue, 28 Sep 2021 18:01:51 +0200
User-agent: Evolution 3.34.2

Hi everyone,

Am Dienstag, den 28.09.2021, 05:36 -0400 schrieb Mark H Weaver:
> Hi Simon,
> 
> zimoun <zimon.toutoune@gmail.com> writes:
> > On Fri, 17 Sept 2021 at 01:40, Mark H Weaver <mhw@netris.org>
> > wrote:
> > > Liliana Marie Prikler <liliana.prikler@gmail.com> wrote:
> [...]
> > > > If done this way, there'd be the benefit that modules with
> > > > packages
> > > > using this thing would have to explicitly request the presence
> > > > of the
> > > > symbol through their use-modules clauses.
> > > 
> > > Actually, for better or worse, Guile's '@@' form does not require
> > > the named module to be imported using 'use-modules', so I don't
> > > think this benefit strictly exists as stated above.  However, I
> > > agree that it's  good practice to list all imported modules in
> > > the '#:use-module' clauses at the top of the file wherever
> > > possible [*], and that there may be somebenefit in declaring the
> > > use of 'computed-origins' at the top of each file.
> > 
> > I am not deeply familiar with Guile module.
> > 
> > I chose to put this in (guix packages) instead of its own module
> > because the module would contain only one function and nothing
> > exported.  The aim for now, as discussed, is to not make this
> > 'method' part of the public API.
If so, one could argue that (gnu packages) is a better location to hide
it, but my main issue is that we still need to hide it!  This will
cause other channels to refer to it using @@ or roll their own
implementations.

> > Then if the function is not exported by the module, the '#:use-
> > module' does not have an effect, right?
> 
> It's true that it would have no effect on the set of available
> bindings, and that's an excellent point.  Perhaps Liliana could
> clarify what she had in mind, or better yet, propose a patch.
I would argue that something like computed-origin-method *does* deserve
to be an exported binding, but ought not to be grouped together into
(guix packages).  The latter only provides record types, not methods
(which are typically implemented elsewhere), and I'd like to keep it
that way.

I've attached a patch to illustrate my point, but please don't apply it
as is.  I have not put in the necessary git blame research to find out
who would need to be copyrighted here.

Regards,
Liliana

Attachment: 0001-guix-Add-computed-origins.patch
Description: Text Data


reply via email to

[Prev in Thread] Current Thread [Next in Thread]