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

[zimoun]

Hi,

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

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 hypothetical probabilities to evaluate are:

 - what would be the probability that a new package having a promise
as origin-uri is not indeed a package with a computed-origin-method?
vs
 - what would be the probability that a new package using
computed-origin-method is not part of either (gnu packages gnuzilla)
or (gnu packages linux)?

Anyway!  Well, I am not convinced that it is worth to tackle these
hypothetical issues. :-)

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.

*refactorize: I think (guix packages) is better because it defines
'<origin>' and other tooling friends.  Because
'computed-origin-method' is somehow a temporary tool about origin,
i.e., a mechanism to define packages, it makes sense to me to put it
there.  However, (gnu packages) is about tools to deal with packages,
not to define them; although one could argue that 'search-patch' is
there is used to define package. For what my rationale behind the
choice of (guix packages) is worth.  And indeed, I have only
half-mentioned this rationale.


As I said, generating this sources.json file by the website is clunky.
Somehow, it is a quick hack to have something up waiting The Right
Way; the long-term generations should be done through the Data
Service, as it had been already discussed but not yet implemented.
Help welcome. :-)


> > 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.
>
> What I was trying to say was that you wouldn't need to rebuild the guix
> package before applying the 50515 changes, which this one seems to
> require.  Again, I'm not 100% sure that's the case, but IIUC (gnu
> packages) is its own realm in this regard.

Hum, maybe there is a misunderstanding here.  On one hand 50620
applies to the guix.git repo and on the other hand 50515 applies to
guix-artwork.git repo.

To have the sources of linux-libre and icecat reported in sources.json
and thus to get a chance to have them archived by SWH, we need:

 a- if computed-origin-method is factorized then update the guix
package (Guix as a library) else do nothing; patch applied to guix.git
 b- tweak how sources.json is built; patch applied to guix-artwork.git

Well, the aim of 50620 is to deal with a) whereas the aim of 50515 is
to deal with b).  Note that 50515 requires a v2 if
computed-origin-method is factorized.

Maybe I miss something.  From my understanding, all the modules are
part of Guix as a library.  Therefore, it does not depends on where we
refactorize.



To be honest, I thought that this tiny improvement of the SWH coverage
would have been much more easier and that that trivial task would not
have taken more than 15 days with lengthy discussions. :-)

> I do have some opinions on that, but I'll type them out in response to
> Ludo, so as to not repeat myself too often.

Thanks.  I will comment overthere or maybe raise the discussion to guix-devel.

All the best,
simon