On Wed, Aug 10, 2016 at 9:42 AM, Ricardo Wurmus <rek...@elephly.net> wrote: > > Ben Woodcroft <b.woodcr...@uq.edu.au> 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?
+1 - Dave
