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

[zimoun]

Hi,

On Wed, 29 Sept 2021 at 12:10, Liliana Marie Prikler
<liliana.prikler@gmail.com> wrote:

> Perhaps we're bikeshedding, but you started to shed the bike when you
> chose to move this procedure to (guix packages) rather than
> implementing one of Mark's suggestions in [0].  I do think we should
> allow for bikeshedding comments from both sides if that is the case.

I do not have time to bikeshed. :-)  (Even if I like to practise it. ;-))

(Note that Mark agreed on my proposal as a variant of one of their
suggestions [0].)

0: <http://issues.guix.gnu.org/50515#5>


> I don't think #50515 is "perfect as-is", though.  Mark's (1) suggestion
> was to put computed-origin-method into its own module, which is the
> same as my long-term position.  Mark suggested a short-term fix (2) of
> still comparing by eq?, which I believe you dismissed for the wrong
> reasons.  Yes, you would still need to check the promise, but you
> wouldn't invert said check, i.e. you would still first look for the
> method and then assert that the uri makes sense.  I think it is safer
> to err on the side of conservatism here rather than claim that this
> code will work for future computed-origin-esque methods.

Maybe.  Well, I commented there [1], reworded here:

The option (1) with its own module means make computed-origin-method
public which implies a lengthy discussion, therefore it is not an
option for me.  We agree an option (1), I guess. ;-)  From my point of
view, the long-term solution is to improve snippet and remove this
computed-origin-method; not make it public.

Perhaps I am wrong about option (2) -- my claim is that
computed-origin-method is *always* used with a promise so it is for
sure an half-baked guess but enough; and it avoids to hard code the
modules from where the packages come from.  Therefore, option (2) does
not improve, IMHO.

For sure, I am right about this [1]:

--8<---------------cut here---------------start------------->8---
However, I would not like that the sources.json situation stays blocked
by the computed-origin-method situation when sources.json is produced by
the website independently of Guix, somehow. :-)
--8<---------------cut here---------------end--------------->8---

because it is exactly what it is: blocked by the
computed-origin-method situation.

1: <http://issues.guix.gnu.org/50515#4>


> Instead of doing either (1) or (2), you opted for your own solution
> (3), which is to put this method into (guix packages).  In my personal
> opinion, this is a half-baked solution, because it puts computed-
> origin-method into the (guix ...) without addressing any of the more
> fundamental issues raised by Mark.  If you really, really can't put
> this into its own module, then I'd at least suggest (3a), which is to
> put it into (gnu packages) instead.  That way, the definition is at
> least closer to where it's used and it's clearer that it's a hack to
> package certain things, not a core part of Guix.  Perhaps you can even
> make use of it without needing to rebuild the guix package in [2/2],
> but don't quote me on that.

All the solutions are half-baked! :-)  Also, generating this
sources.json using the website is half-backed at first. ;-)

Options (1) and (2) are more half-baked than my initial submission (3)
(guix packages) or (3a) (gnu packages), IMHO.

I still think that (guix packages) is better than (gnu packages).
Maintainers, what do you think?

About update guix package [2/2], it has to be done, IIUC.  The file
sources.json contains what the package guix provides, not what the
current Guix has.  The website -- built using the Guile tool haunt --
uses Guix as a Guile library.  Maybe I miss something.

> For the right amount of incremental change, I'd suggest the following:
> Try to see whether you can do with computed-origin-method in (gnu
> packages) and without rebuilding the guix package, and if so, submit a

This is what I suggested earlier ;-) [2]: send a v2 moving to '(gnu
packages)' instead and rename to 'compute-origin'.  Although I
disagree on (gnu packages). :-)

I need explanations if rebuild the guix package is not necessary.

2: <http://issues.guix.gnu.org/50620#8>

> If you are also interested in the more long-term discussion of allowing
> computed origins into the (guix) tree, I suggest sending a v2 patch to
> this thread, which creates a new module, adds documentation, and so on,
> and so forth, and also link to it on guix-devel.  For the time being,
> this v2 should also refrain from touching anything that uses the
> current computed-origin-method, as that can be addressed in rather
> simple follow-up commits, particularly if we also implement a #50515-v2
> before.  Then we can fully use this to bikeshed about making it a verb
> and what not.

For long-term, the road seems to improve the 'snippet' mechanism, not
make computed-origin-method public, IMHO.

All the best,
simon