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

[Mark H Weaver <mhw@netris.org>]

Hi Simon,

zimoun <zimon.toutoune@gmail.com> writes:

> On Wed, 29 Sept 2021 at 16:36, Liliana Marie Prikler
> <liliana.prikler@gmail.com> wrote:
>
>> > 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.
>>
>> The probability of having a promise when using computed-origin-method
>> is 100%.  What is the probability of having computed-origin-method when
>> you see a promise?  The answer is: we don't know.  We can see from the
>
> You mean, what is the probability of having a computed-origin-method
> when the origin-uri is a promise?  We do not know, but pragmatically,
> for now 100%. :-)

To my mind, that's not good enough.  I consider it unsafe, and poor
programming practice, to force a promise without first knowing what that
promise represents and what are the implications of forcing it.

In projects as large as Guix, if it becomes accepted practice to
introduce lots of assumptions scattered around the code that are
"for now 100%" true, the result is eventually a very brittle project
where it's difficult to make changes without random stuff breaking.

> Option (2) is:
>
>  ___ (or (eq? method (@@ (gnu packages gnuzilla) computed-origin-method))
>  _______ (eq? method (@@ (gnu packages linux) computed-origin-method)))
>
> then I ask you similarly: what is the probability of having packages
> using computed-origin-method in these 2 modules only?  We do not know,
> but pragmatically, for now 100%. :-)

The potential failure mode here is far less bad.  In this case, if
someone else makes another clone of 'computed-origin-method' in another
module and forgets to update this code, the worst case is that some
source code fails to be added to SWH.  Incidentally, I guess that's the
same outcome that would happen if someone adds a brand new
'origin-method' and forgets to update this code.

Incidentally, I have a suggestion for how to avoid that failure mode
properly, once and for all: issue a warning if we're unable to identify
the 'method' of the origin at hand, calling attention to the fact that
there's an unhandled case in this code.  This is precisely analogous to
Standard ML's *very* useful feature of issuing warnings at compile time
in case of an non-exhaustive 'match' form.

What do you think?

In any case, thanks very much for your efforts to push this issue toward
resolution.

      Regards,
        Mark

-- 
Disinformation flourishes because many people care deeply about injustice
but very few check the facts.  Ask me about <https://stallmansupport.org>.