Re: [PATCH] ui: 'package->recutils' serializes the source field.

[Ricardo Wurmus]

Ben Woodcroft <address@hidden> writes:

> On 10/08/16 22:27, David Craven wrote:
>>> I don't have anything to to contribute beyond psuedo-quoting Ludo: let's 
>>> not lose our hair over this!
>> I'll let the fact that that could interpreted as being insulting slide.
>>
>
> Oh, no that wasn't my intended meaning. I just saw this thread getting a 
> bit heated in general and I wanted to help it in the reverse direction, 
> for all concerned. That's all.

I agree, let’s cool it a bit please.

Aside from the possible FDSG issue (which I need to think about before
forming an opinion, although I’m leaning towards not seeing it as a
problem), I’m not yet convinced that all fields need to be printed in
recutils format.

For programmatic access to packages we recommend using the Scheme values
directly as they also hold additional information about the location of
a value in the dependency graph (package expressions are code, not plain
meta-data).  I always understood the recutils output to be just a user
interface for the command line, which is why it doesn’t need to and
probably shouldn’t print *all* fields.

I think it is not desirable to show that much more information in the
output, because it is not a programming interface but primarily a user
interface.

Even so, if one insisted on using the recutils output in a programmatic
fashion (e.g. in a bash script), it would be best to run “guix build
--source” on the package names to obtain the actual source tarballs that
are used by Guix.  What would be the point of printing a URL that is not
necessarily used by Guix directly?  “guix build --source” (which can be
used in bash scripts) already provides the *actual* tarball (patched and
with snippets applied), so this would be more meaningful than an
upstream URL, in my opinion.

What do others think?

~~ Ricardo