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

[zimoun <zimon.toutoune@gmail.com>]

Hi Mark,

On Wed, 29 Sep 2021 at 17:40, Mark H Weaver <mhw@netris.org> wrote:
> zimoun <zimon.toutoune@gmail.com> writes:

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

I agree…

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

…and I also agree.  That’s why, right after this quotation, I wrote:

        That's why the option (3):

           (eq? method (@@ (guix packages) computed-origin-method))

        which means refactorize*.  It is somehow the two worlds: check i.e.,
        safer, no modules hard-coded and keep private the time to have The
        Right Plan for this computed-origin-method.

which is *exactly* what you are asking, IIUC.

To be honest, I do not understand why we are discussing at length this
trivial path:

for guix.git:

 1. move the duplicate computed-origin-method to a single place
 2. keep it private
 3. add comments about that

for guix-artwork.git:

 4. guard the promise using a check against:
      (@@ (module somewhere) computed-origin-method)

for guix.git

 5. update the package guix

done! :-)

It changes nothing on the Guix side.

Do we not agree on this trivial path?  Re-reading from the starting
point 50515 and then 50620, the trivial road appears to me clear.  I
apologize if it was not or to not make it explicit earlier.

From my understanding, we all agree, somehow; because it fixes the
current situation and let the time to cook The Right Plan for this
computed-origin-method.  Where we can discuss is #2 but as it is already
mentioned, it is out of scope for sources.json, IMHO.

If I knew all what would happen, then I would send a v2 for 50515 using
what you described as option (2). :-) My aim with this 50620 was just to
simplify at very low cost the code (belonging to the repo
guix-artwork.git) which generates <https://guix.gnu.org/sources.json>.

The v2 (adding a guard) for 50515 is simply waiting the output of this
50620; because this guard depends if computed-origin-method is defined
at an unique location or at two different locations.
  

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

The SWH reader which consumes this sources.json file does not care about
a warning.  And AFAIK no one is reviewing by hand this sources.json
file.  Specifically, the only purpose of this very file is to be
consumed by the SWH infrastructure.  It is automatically generated when
the Guix website rebuilds; the content of this file depends on the
version of the package guix.

That’s said, there is room of improvement to track what is the archival
coverage by SWH.  Today, we do not have a clear picture of the packages
archived by SWH.  By archived, it means packages for which Guix is able
to fallback and lookup using the SWH archive.  Well, now one foot, now
the other. :-)

(On a side note, I agree that this ML feature is very useful.  From my
understanding, it requires a kind of type system that Guile does not
have.  Sadly.)

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

Thanks.  At one point, I felt demotivated then reconsidering the energy
we all are putting it, we have to resolve. :-)

All the best,
simon