Re: How to get the package metadata as structured data?

Re: How to get the package metadata as structured data?

[David Craven]

Hi Philippe,

Thank you for your interest in guix =)

All package metadata can be accessed easily through scheme. There is
no way to export this data currently, although it probably wouldn't be
too hard to implement.

The approach I was planning on taking is the following:
Take a package, remove all build-phases except unpack, add a phase to
run scancode and add the output json to the store.

This way guix already takes care of fetching and unpacking the package
and caching the result. Unless a build input changes, for example
scancode (an input to the scancode phase) is updated, or a scanned
package is updated, running a tool that I'll call `guix license` for
now will work of the json file that was already generated. This means
that improving the reporting or postprocessing the results doesn't
require rescanning a dependency.

Maybe someone else has other/better ;-) thoughts on this?

Cheers
David

Re: How to get the package metadata as structured data?

[Ludovic Courtès]

Hi!

David Craven <david@craven.ch> skribis:

> All package metadata can be accessed easily through scheme. There is
> no way to export this data currently, although it probably wouldn't be
> too hard to implement.

One way is:

  guix package -s .

which returns a recutils database¹, which is essentially plain text.

Alternately we could write a snippet to export it as JSON if you prefer.

Ludo’.

¹ https://gnu.org/s/recutils/manual/html_node/The-Rec-Format.html

RE: How to get the package metadata as structured data?

[Cook, Malcolm]

Hi,

Could the guix project please make available the results of `guix package -s .` that would list all available packages in recutils format for those who do not (yet) have fully functioning guix install?

Thanks?


 > -----Original Message-----
 > From: Guix-devel [mailto:guix-devel-bounces+mec=stowers.org@gnu.org]
 > On Behalf Of Ludovic Courtès
 > Sent: Thursday, August 04, 2016 4:09 PM
 > To: Philippe Ombredanne <pombredanne@nexb.com>; David Craven
 > <david@craven.ch>
 > Cc: guix-devel <guix-devel@gnu.org>
 > Subject: Re: How to get the package metadata as structured data?
 > 
 > Hi!
 > 
 > David Craven <david@craven.ch> skribis:
 > 
 > > All package metadata can be accessed easily through scheme. There is
 > > no way to export this data currently, although it probably wouldn't be
 > > too hard to implement.
 > 
 > One way is:
 > 
 >   guix package -s .
 > 
 > which returns a recutils database¹, which is essentially plain text.
 > 
 > Alternately we could write a snippet to export it as JSON if you prefer.
 > 
 > Ludo’.
 > 
 > ¹ https://gnu.org/s/recutils/manual/html_node/The-Rec-Format.html

Re: How to get the package metadata as structured data?

[David Craven]

This should works, but it's pretty slow...

guix package --list-available | grep -o --regex "^[a-zA-Z0-9-]*" |
xargs -n1 guix package -s 1> guix-metadata.txt

time sh -c "guix package -s guix &> /dev/null"
sh -c "guix package -s guix &> /dev/null"  2.42s user 0.07s system
113% cpu 2.203 total

Re: How to get the package metadata as structured data?

[David Craven]

I aborted, since I realised that guix package -s doesn't include the
source url and hash, which would be important for a testsuite...

Some interesting measurements:
guix package --list-available | grep -o --regex "^[a-zA-Z0-9-]*" | wc -l
3797

cat guix-metadata.txt | grep --regex "^name: .*$" | wc -l
13949

looks like we have many package variants?

and an example of what guix package -s guix exports

guix package -s guix
name: guix
version: 0.10.0
outputs: out
systems: x86_64-linux i686-linux armhf-linux mips64el-linux
dependencies: bzip2-1.0.6 emacs-magit-popup-2.7.0 emacs-minimal-24.5
geiser-0.8.1
+ gnutls-3.5.2 guile-2.0.11 guile-json-0.5.0 gzip-1.8 libgcrypt-1.7.0
pkg-config-0.29
+ sqlite-3.12.2 zlib-1.2.8
location: gnu/packages/package-management.scm:71:2
homepage: http://www.gnu.org/software/guix
license: GPL 3+
synopsis: Functional package manager for installed software packages
and versions
description: GNU Guix is a functional package manager for the GNU
system, and is also
+ a distribution thereof.  It includes a virtual machine image.
Besides the usual
+ package management features, it also supports transactional upgrades
and roll-backs,
+ per-user profiles, and much more.  It is based on the Nix package manager.

name: guix
version: 0.10.0-1.97c8
outputs: out
systems: x86_64-linux i686-linux armhf-linux mips64el-linux
dependencies: autoconf-wrapper-2.69 automake-1.15 bzip2-1.0.6
emacs-magit-popup-2.7.0
+ emacs-minimal-24.5 geiser-0.8.1 gettext-0.19.8 gnutls-3.5.2 graphviz-2.38.0
+ guile-2.0.11 guile-json-0.5.0 gzip-1.8 help2man-1.47.4 libgcrypt-1.7.0
+ pkg-config-0.29 sqlite-3.12.2 texinfo-6.1 zlib-1.2.8
location: gnu/packages/package-management.scm:216:4
homepage: http://www.gnu.org/software/guix
license: GPL 3+
synopsis: Functional package manager for installed software packages
and versions
description: GNU Guix is a functional package manager for the GNU
system, and is also
+ a distribution thereof.  It includes a virtual machine image.
Besides the usual
+ package management features, it also supports transactional upgrades
and roll-backs,
+ per-user profiles, and much more.  It is based on the Nix package manager.

Re: How to get the package metadata as structured data?

[Aljosha Papsch]

[-- Attachment #1: Type: text/plain, Size: 2479 bytes --]

guix package prints its output in rec format. You can use recutils to process the output.

Am 5. August 2016 13:04:49 MESZ, schrieb David Craven <david@craven.ch>:
>I aborted, since I realised that guix package -s doesn't include the
>source url and hash, which would be important for a testsuite...
>
>Some interesting measurements:
>guix package --list-available | grep -o --regex "^[a-zA-Z0-9-]*" | wc
>-l
>3797
>
>cat guix-metadata.txt | grep --regex "^name: .*$" | wc -l
>13949
>
>looks like we have many package variants?
>
>and an example of what guix package -s guix exports
>
>guix package -s guix
>name: guix
>version: 0.10.0
>outputs: out
>systems: x86_64-linux i686-linux armhf-linux mips64el-linux
>dependencies: bzip2-1.0.6 emacs-magit-popup-2.7.0 emacs-minimal-24.5
>geiser-0.8.1
>+ gnutls-3.5.2 guile-2.0.11 guile-json-0.5.0 gzip-1.8 libgcrypt-1.7.0
>pkg-config-0.29
>+ sqlite-3.12.2 zlib-1.2.8
>location: gnu/packages/package-management.scm:71:2
>homepage: http://www.gnu.org/software/guix
>license: GPL 3+
>synopsis: Functional package manager for installed software packages
>and versions
>description: GNU Guix is a functional package manager for the GNU
>system, and is also
>+ a distribution thereof.  It includes a virtual machine image.
>Besides the usual
>+ package management features, it also supports transactional upgrades
>and roll-backs,
>+ per-user profiles, and much more.  It is based on the Nix package
>manager.
>
>name: guix
>version: 0.10.0-1.97c8
>outputs: out
>systems: x86_64-linux i686-linux armhf-linux mips64el-linux
>dependencies: autoconf-wrapper-2.69 automake-1.15 bzip2-1.0.6
>emacs-magit-popup-2.7.0
>+ emacs-minimal-24.5 geiser-0.8.1 gettext-0.19.8 gnutls-3.5.2
>graphviz-2.38.0
>+ guile-2.0.11 guile-json-0.5.0 gzip-1.8 help2man-1.47.4
>libgcrypt-1.7.0
>+ pkg-config-0.29 sqlite-3.12.2 texinfo-6.1 zlib-1.2.8
>location: gnu/packages/package-management.scm:216:4
>homepage: http://www.gnu.org/software/guix
>license: GPL 3+
>synopsis: Functional package manager for installed software packages
>and versions
>description: GNU Guix is a functional package manager for the GNU
>system, and is also
>+ a distribution thereof.  It includes a virtual machine image.
>Besides the usual
>+ package management features, it also supports transactional upgrades
>and roll-backs,
>+ per-user profiles, and much more.  It is based on the Nix package
>manager.

-- 
Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail gesendet.

[-- Attachment #2: Type: text/html, Size: 3068 bytes --]

Re: How to get the package metadata as structured data?

[Philippe Ombredanne]

David Craven <david@craven.ch> wrote:
> I aborted, since I realised that guix package -s doesn't include the
> source url and hash, which would be important for a testsuite...

IMHO, if the rec data is the only way to get to the packages data, the
source url would be rather essential to get in.

-- 
Cordially
Philippe Ombredanne

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

[David Craven]

* guix/ui.scm (package->recutils): Format origin.
---
 guix/ui.scm | 18 ++++++++++++++++++
 1 file changed, 18 insertions(+)

diff --git a/guix/ui.scm b/guix/ui.scm
index 4d1b65c..e232548 100644
--- a/guix/ui.scm
+++ b/guix/ui.scm
@@ -26,6 +26,7 @@
 (define-module (guix ui)
   #:use-module (guix utils)
   #:use-module (guix store)
+  #:use-module (guix base32)
   #:use-module (guix config)
   #:use-module (guix packages)
   #:use-module (guix profiles)
@@ -33,6 +34,7 @@
   #:use-module (guix combinators)
   #:use-module (guix build-system)
   #:use-module (guix serialization)
+  #:use-module (guix git-download)
   #:use-module ((guix build utils) #:select (mkdir-p))
   #:use-module ((guix licenses) #:select (license? license-name))
   #:use-module ((guix build syscalls) #:select (terminal-columns))
@@ -878,6 +880,22 @@ WIDTH columns."
   ;; Note: Don't i18n field names so that people can post-process it.
   (format port "name: ~a~%" (package-name p))
   (format port "version: ~a~%" (package-version p))
+
+  (let ((uri (origin-uri (package-source p))))
+    (cond
+      ((git-reference? uri)
+        (begin
+          (format port "source-git-url: ~a~%"
+                       (git-reference-url uri))
+          (format port "source-git-commit: ~a~%"
+                       (git-reference-commit uri))
+          (format port "source-git-recursive: ~a~%"
+                       (git-reference-recursive? uri))))
+      (#t
+        (format port "source-uri: ~a~%" uri))))
+
+  (format port "source-hash: ~a~%" (bytevector->base32-string
+                                      (origin-sha256 (package-source p))))
   (format port "outputs: ~a~%" (string-join (package-outputs p)))
   (format port "systems: ~a~%"
           (string-join (package-transitive-supported-systems p)))
-- 
2.9.0

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

[Alex Kost]

David Craven (2016-08-05 17:58 +0300) wrote:

> * guix/ui.scm (package->recutils): Format origin.
> ---
>  guix/ui.scm | 18 ++++++++++++++++++
>  1 file changed, 18 insertions(+)
>
>
> diff --git a/guix/ui.scm b/guix/ui.scm
> index 4d1b65c..e232548 100644
> --- a/guix/ui.scm
> +++ b/guix/ui.scm
> @@ -26,6 +26,7 @@
>  (define-module (guix ui)
>    #:use-module (guix utils)
>    #:use-module (guix store)
> +  #:use-module (guix base32)
>    #:use-module (guix config)
>    #:use-module (guix packages)
>    #:use-module (guix profiles)
> @@ -33,6 +34,7 @@
>    #:use-module (guix combinators)
>    #:use-module (guix build-system)
>    #:use-module (guix serialization)
> +  #:use-module (guix git-download)
>    #:use-module ((guix build utils) #:select (mkdir-p))
>    #:use-module ((guix licenses) #:select (license? license-name))
>    #:use-module ((guix build syscalls) #:select (terminal-columns))
> @@ -878,6 +880,22 @@ WIDTH columns."
>    ;; Note: Don't i18n field names so that people can post-process it.
>    (format port "name: ~a~%" (package-name p))
>    (format port "version: ~a~%" (package-version p))
> +
> +  (let ((uri (origin-uri (package-source p))))

This will fail for some packages (for example, for 'gcc-toolchain')
because the source value can be #f, and (origin-uri #f) errors.

> +    (cond
> +      ((git-reference? uri)
> +        (begin

'begin' is not needed here.

> +          (format port "source-git-url: ~a~%"
> +                       (git-reference-url uri))
> +          (format port "source-git-commit: ~a~%"
> +                       (git-reference-commit uri))
> +          (format port "source-git-recursive: ~a~%"
> +                       (git-reference-recursive? uri))))
> +      (#t

I think using 'else' here would be more Schemey than '#t'.

> +        (format port "source-uri: ~a~%" uri))))
> +
> +  (format port "source-hash: ~a~%" (bytevector->base32-string
> +                                      (origin-sha256 (package-source p))))
>    (format port "outputs: ~a~%" (string-join (package-outputs p)))
>    (format port "systems: ~a~%"
>            (string-join (package-transitive-supported-systems p)))

After all I would write it like this:

  (let ((source (package-source p)))
    (when (origin? source)
      (let ((uri (origin-uri source)))
        (cond
         ((git-reference? uri)
          (format port "source-git-url: ~a~%"
                  (git-reference-url uri))
          (format port "source-git-commit: ~a~%"
                  (git-reference-commit uri))
          (format port "source-git-recursive: ~a~%"
                  (git-reference-recursive? uri)))
         (else
          (format port "source-uri: ~a~%" uri))))
      (format port "source-hash: ~a~%"
              (bytevector->base32-string (origin-sha256 source)))))

However, I'm not sure whether all these source things are needed to be
in the output, I would wait for other opinions.

(I agree with you though and I would like to add the same info for Emacs
interface :-))

Also note that packages may have multiple sources.  For example, for
'sudo' package, the output will be:

  source-uri: (https://www.sudo.ws/sudo/dist/sudo-1.8.17p1.tar.gz ftp://ftp.sudo.ws/pub/sudo/OLD/sudo-1.8.17p1.tar.gz)

I'm not sure if this is a desired formatting, WDYT?

-- 
Alex

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

[David Craven]

Hi Alex,

> I'm not sure if this is a desired formatting, WDYT?

No that's not a desired formatting, it should be space separated like
the systems list IMO.

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

[Mathieu Lirzin]

Alex Kost <alezost@gmail.com> writes:

> David Craven (2016-08-05 17:58 +0300) wrote:
>
>> * guix/ui.scm (package->recutils): Format origin.
>> ---
>>  guix/ui.scm | 18 ++++++++++++++++++
>>  1 file changed, 18 insertions(+)
>>
>>
>> diff --git a/guix/ui.scm b/guix/ui.scm
>> index 4d1b65c..e232548 100644
>> --- a/guix/ui.scm
>> +++ b/guix/ui.scm
>> @@ -26,6 +26,7 @@
>>  (define-module (guix ui)
>>    #:use-module (guix utils)
>>    #:use-module (guix store)
>> +  #:use-module (guix base32)
>>    #:use-module (guix config)
>>    #:use-module (guix packages)
>>    #:use-module (guix profiles)
>> @@ -33,6 +34,7 @@
>>    #:use-module (guix combinators)
>>    #:use-module (guix build-system)
>>    #:use-module (guix serialization)
>> +  #:use-module (guix git-download)
>>    #:use-module ((guix build utils) #:select (mkdir-p))
>>    #:use-module ((guix licenses) #:select (license? license-name))
>>    #:use-module ((guix build syscalls) #:select (terminal-columns))
>> @@ -878,6 +880,22 @@ WIDTH columns."
>>    ;; Note: Don't i18n field names so that people can post-process it.
>>    (format port "name: ~a~%" (package-name p))
>>    (format port "version: ~a~%" (package-version p))
>> +
>> +  (let ((uri (origin-uri (package-source p))))
>
> This will fail for some packages (for example, for 'gcc-toolchain')
> because the source value can be #f, and (origin-uri #f) errors.
>
>> +    (cond
>> +      ((git-reference? uri)
>> +        (begin
>
> 'begin' is not needed here.
>
>> +          (format port "source-git-url: ~a~%"
>> +                       (git-reference-url uri))
>> +          (format port "source-git-commit: ~a~%"
>> +                       (git-reference-commit uri))
>> +          (format port "source-git-recursive: ~a~%"
>> +                       (git-reference-recursive? uri))))
>> +      (#t
>
> I think using 'else' here would be more Schemey than '#t'.
>
>> +        (format port "source-uri: ~a~%" uri))))
>> +
>> +  (format port "source-hash: ~a~%" (bytevector->base32-string
>> +                                      (origin-sha256 (package-source p))))
>>    (format port "outputs: ~a~%" (string-join (package-outputs p)))
>>    (format port "systems: ~a~%"
>>            (string-join (package-transitive-supported-systems p)))
>
> After all I would write it like this:
>
>   (let ((source (package-source p)))
>     (when (origin? source)
>       (let ((uri (origin-uri source)))
>         (cond
>          ((git-reference? uri)
>           (format port "source-git-url: ~a~%"
>                   (git-reference-url uri))
>           (format port "source-git-commit: ~a~%"
>                   (git-reference-commit uri))
>           (format port "source-git-recursive: ~a~%"
>                   (git-reference-recursive? uri)))
>          (else
>           (format port "source-uri: ~a~%" uri))))
>       (format port "source-hash: ~a~%"
>               (bytevector->base32-string (origin-sha256 source)))))
>
> However, I'm not sure whether all these source things are needed to be
> in the output, I would wait for other opinions.
>
> (I agree with you though and I would like to add the same info for Emacs
> interface :-))
>
> Also note that packages may have multiple sources.  For example, for
> 'sudo' package, the output will be:
>
>   source-uri: (https://www.sudo.ws/sudo/dist/sudo-1.8.17p1.tar.gz ftp://ftp.sudo.ws/pub/sudo/OLD/sudo-1.8.17p1.tar.gz)

I don't have an opinion on what should be displayed or not (at least not
yet).  However I think there is an issue with FSDG compliance here, when
upstream includes non-free stuff for the same reason that 'guix build
--source PACKAGE' is required by FSDG to provide a cleaned version of the
tarball.

"source-uris" should point to the same thing that 'guix build -S
PACKAGE' provides however in our current infrastructure this is not
possible.

For the same reason I think Emacs interface should not display the
origin URL of those packages.  I Don't know how to achieve this, maybe
displaying only the URL when there is no snippet part would work even if
it will remove more package source URLs than needed.

WDYT?

-- 
Mathieu Lirzin

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

[David Craven]

If I understand you correctly, you are saying the following:

We shouldn't display an url to a tarball that may contain unfree
software, because a user might run `guix package -s` download the
tarball from the source-uris field and build and run the code, and
accidentally run nonfree software on his computer?

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

[Mathieu Lirzin]

David Craven <david@craven.ch> writes:

> If I understand you correctly, you are saying the following:
>
> We shouldn't display an url to a tarball that may contain unfree
> software, because a user might run `guix package -s` download the
> tarball from the source-uris field and build and run the code, and
> accidentally run nonfree software on his computer?

No, this is not what I am saying.

'guix build -S' does already provide a patched version of the tarball
without the non-free stuff.  So the user can't install non-free code
accidentally.  IIRC This behavior was introduced to comply with FSDG in
order to make GuixSD a fully free distro.

My point is that if we are giving a direct link to the non-patched
source in our UI, the FSDG issue is the same.

Sorry if I was unclear.

-- 
Mathieu Lirzin

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

[David Craven]

I meant the little -s flag...

-s, --search=REGEXP    search in synopsis and description using REGEXP

and I meant download, build and run manually outside of guix.

It still sounds like that's what you are saying... ;-)

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

[David Craven]

> My point is that if we are giving a direct link to the non-patched
> source in our UI, the FSDG issue is the same.

Just because I can't understand the concern, doesn't necessarily
mean that it isn't a valid one...

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

[Mathieu Lirzin]

David Craven <david@craven.ch> writes:

> I meant the little -s flag...
>
> -s, --search=REGEXP    search in synopsis and description using REGEXP
>
> and I meant download, build and run manually outside of guix.
>
> It still sounds like that's what you are saying... ;-)

oops my bad.  So your summary of what I was saying was indeed correct.

-- 
Mathieu Lirzin

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

[David Craven]

Quoting FSDG:
A free system distribution must not steer users towards obtaining any
nonfree information for practical use, or encourage them to do so.

We are not steering or encouraging users to do any thing by displaying
the source url of the tarball, we are merely providing factual
non-opinionated information. But I guess we aren't telling the full
story and should tell the user that we made post download
modifications to the tarball to comply with the free software
distribution guidelines.

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

[Mathieu Lirzin]

David Craven <david@craven.ch> writes:

> Quoting FSDG:
> A free system distribution must not steer users towards obtaining any
> nonfree information for practical use, or encourage them to do so.
>
> We are not steering or encouraging users to do any thing by displaying
> the source url of the tarball, 

That's an interpretation of it.  I think that point deserves a
discussion on <gnu-linux-libre@nongnu.org> mailing list, before
including such change in Guix UI.

For some background on the 'guix build --source' issue, Please read the
full thread on
https://lists.nongnu.org/archive/html/gnu-linux-libre/2013-09/msg00001.html.

>we are merely providing factual non-opinionated information.

IMO, Distributing software is always opinionated.  :)

-- 
Mathieu Lirzin

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

[David Craven]

Quoting Ludo from the thread you mentioned:

> (Besides, our package meta-data would probably still refer to the “real”
> home page of the package, from which it’s trivial to get the unmodified
> tarball.)

The discussion only applies to 'guix build --source' and I can't see any
indication from reading the thread that displaying the original source url
would be in any way problematic. Can you quote something from that
thread that would indicate otherwise?

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

[Mathieu Lirzin]

David Craven <david@craven.ch> writes:

> Quoting Ludo from the thread you mentioned:
>
>> (Besides, our package meta-data would probably still refer to the “real”
>> home page of the package, from which it’s trivial to get the unmodified
>> tarball.)
>
> The discussion only applies to 'guix build --source' and I can't see any
> indication from reading the thread that displaying the original source url
> would be in any way problematic. Can you quote something from that
> thread that would indicate otherwise?

I don't need to quote anything to think that:

- Providing a user tool to fetch a tarball
- Displaying a direct link to a tarball in our UI

... have the same "steer users" effect.  

Feel free to disagree, however when doubt emerges about FSDG compliance,
a consensus needs to be reached on <gnu-linux-libre@nongnu.org>.  If you
want your change to be included in Guix, please start a discussion on
that mailing list explaining what you are proposing and ask if other
people thinks this is OK in regards of the FSDG.

-- 
Mathieu Lirzin

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

[David Craven]

> Feel free to disagree, however when doubt emerges about FSDG compliance,
> a consensus needs to be reached on <gnu-linux-libre@nongnu.org>.  If you
> want your change to be included in Guix, please start a discussion on
> that mailing list explaining what you are proposing and ask if other
> people thinks this is OK in regards of the FSDG.

I am not going to do that, since I don't have the time to start
pointless discussions
just to be able to say I told you so.

I hope you can appreciate my restraint in this reply.

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

[Alex Kost]

Mathieu Lirzin (2016-08-08 20:53 +0300) wrote:

> David Craven <david@craven.ch> writes:
>
>> Quoting Ludo from the thread you mentioned:
>>
>>> (Besides, our package meta-data would probably still refer to the “real”
>>> home page of the package, from which it’s trivial to get the unmodified
>>> tarball.)
>>
>> The discussion only applies to 'guix build --source' and I can't see any
>> indication from reading the thread that displaying the original source url
>> would be in any way problematic. Can you quote something from that
>> thread that would indicate otherwise?
>
> I don't need to quote anything to think that:
>
> - Providing a user tool to fetch a tarball
> - Displaying a direct link to a tarball in our UI

But a user already can look at any package info (including the source
URL) using "guix edit" command, so I don't see a reason why "guix
package --show" can't display the same info.

-- 
Alex

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

[Mathieu Lirzin]

Alex Kost <alezost@gmail.com> writes:

> Mathieu Lirzin (2016-08-08 20:53 +0300) wrote:
>
>> David Craven <david@craven.ch> writes:
>>
>>> Quoting Ludo from the thread you mentioned:
>>>
>>>> (Besides, our package meta-data would probably still refer to the “real”
>>>> home page of the package, from which it’s trivial to get the unmodified
>>>> tarball.)
>>>
>>> The discussion only applies to 'guix build --source' and I can't see any
>>> indication from reading the thread that displaying the original source url
>>> would be in any way problematic. Can you quote something from that
>>> thread that would indicate otherwise?
>>
>> I don't need to quote anything to think that:
>>
>> - Providing a user tool to fetch a tarball
>> - Displaying a direct link to a tarball in our UI
>
> But a user already can look at any package info (including the source
> URL) using "guix edit" command, so I don't see a reason why "guix
> package --show" can't display the same info.

I am just claiming that the two things above are equivalent and that as
a consequence we can't refuse one and accept the other.  I am not
discussing the "why", only applying logic.

-- 
Mathieu Lirzin

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

[David Craven]

Hi Mathieu,

Sometimes it's hard to admit when you are wrong, but I think in
practice people barely take notice if you quickly admit you are
wrong and move on. If you drag it out, people are definitively
going to remember.

Claiming that you applied logic to arrive at the conclusion that

- Providing a user tool to fetch a tarball
- Displaying a direct link to a tarball in our UI

are the same thing is nonsense.

Asking me to start a discussion on the linux-libre mailing list over
this is an unreasonable request.

The only way I can see these two things being equal is if you
say:

class Thing
class UserTool extends Thing
class DirectLink extends Thing

typeof UserTool == typeof DirectLink ;-)

I had a class on java - which I didn't attend - and passed
an exam - but I never wrote a single line of java. Pretty
interesting what will pass as a java programmer don't you
think? =P

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

[Mathieu Lirzin]

David Craven <david@craven.ch> writes:

> Sometimes it's hard to admit when you are wrong, but I think in
> practice people barely take notice if you quickly admit you are
> wrong and move on. If you drag it out, people are definitively
> going to remember.
>
> Claiming that you applied logic to arrive at the conclusion that
>
> - Providing a user tool to fetch a tarball
> - Displaying a direct link to a tarball in our UI
>
> are the same thing is nonsense.

If I disagree with you doesn't mean I am wrong.  Please don't act as if
you were in a position to decide who is wrong.  Trying to persuade me
that it would be better for my reputation to agree with you won't work.

> Asking me to start a discussion on the linux-libre mailing list over
> this is an unreasonable request.

Being careful about FSDG compliance is not unreasonable.

> The only way I can see these two things being equal is if you
> say:
>
> class Thing
> class UserTool extends Thing
> class DirectLink extends Thing
>
> typeof UserTool == typeof DirectLink ;-)
>
> I had a class on java - which I didn't attend - and passed
> an exam - but I never wrote a single line of java. Pretty
> interesting what will pass as a java programmer don't you
> think? =P

Sorry, but I don't understand what you are trying to say.

-- 
Mathieu Lirzin

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

[David Craven]

> If I disagree with you doesn't mean I am wrong. Please don't act as if
> you were in a position to decide who is wrong.

You voiced your concern, I tried to find common ground.

You referred to the FSDG. I read it to understand.

You told me it was just my opinion of what is says, and referred me
to a mailing list thread. I read the thread and asked how it relates.

You told me you did not have to provide an answer and I had to
go on some mailing list to start a discussion, so that other people
can argue for you.

I haven't heard you provide an argument other that repeating
it's an FSDG issue, it's an FSDG issue.

That sounds to me like someone who's out of ammo but not willing
to admit it.

> Trying to persuade me that it would be better for my reputation to agree with you won't work.

One can try.

> Sorry, but I don't understand what you are trying to say.

Trying to change the subject and end the mail with a smiley. Not that
I'm particularly skilled at it ;-)

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

[David Craven]

Hi Mathieu,

> No that's not a desired formatting, it should be space separated like
> the systems list IMO.

> But I guess we aren't telling the full
> story and should tell the user that we made post download
> modifications to the tarball to comply with the free software
> distribution guidelines.

Can we move forward on this then if we incorporate Alex's changes and
these suggestions?



I'll provide a few pointers for a stronger argument for the next one
you have (if you don't mind) ;-)

You made the statement that the FSDG wasn't clear enough on the
subject to make a decision and was open for interpretation. Then you
made use of "case law" referring to the guix package -S thread.

You also made the statement:
> I am just claiming that the two things above are equivalent and that as
> a consequence we can't refuse one and accept the other.  I am not
> discussing the "why", only applying logic.

I would have expected you to provide a compelling argument for why
these things are equivalent, since it wasn't obvious to me. Making use
of case law is a valid argument, but you'd have to explain why and how
it applies to cast reasonable doubt that this is a FSDG issue. IMO you
did not do so sufficiently to merit escalating the discussion to a
different mailing list.

David

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

[Mathieu Lirzin]

David Craven <david@craven.ch> writes:

> Hi Mathieu,
>
>> No that's not a desired formatting, it should be space separated like
>> the systems list IMO.
>
>> But I guess we aren't telling the full
>> story and should tell the user that we made post download
>> modifications to the tarball to comply with the free software
>> distribution guidelines.
>
> Can we move forward on this then if we incorporate Alex's changes and
> these suggestions?
>
> I'll provide a few pointers for a stronger argument for the next one
> you have (if you don't mind) ;-)
>
> You made the statement that the FSDG wasn't clear enough on the
> subject to make a decision and was open for interpretation. Then you
> made use of "case law" referring to the guix package -S thread.
>
> You also made the statement:
>> I am just claiming that the two things above are equivalent and that as
>> a consequence we can't refuse one and accept the other.  I am not
>> discussing the "why", only applying logic.
>
> I would have expected you to provide a compelling argument for why
> these things are equivalent, since it wasn't obvious to me. Making use
> of case law is a valid argument, but you'd have to explain why and how
> it applies to cast reasonable doubt that this is a FSDG issue. IMO you
> did not do so sufficiently to merit escalating the discussion to a
> different mailing list.

When someone wants to introduce some change, it is up to him to convince
others to accept this change, not the other way.

This discussion is already escalating in a way where you are waisting
your energy (and mine too), Guix-devel is not the relevant place for
talking about FSDG compliance.  I have already explain my reasons and I
will not repeat myself.  If you don't want to take the time to discuss
this on the relevant mailing list, then nothing will move unless you
convince the Guix maintainers that my doubt are not legitimate.

-- 
Mathieu Lirzin

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

[David Craven]

> unless you convince the Guix maintainers that my doubt are not legitimate

I'm sorry but I haven't heard anyone except you express doubt. I made
several arguments to which you did not respond. Who else except you do
you think I have to convince? You made no effort on your part as I
explained in the previous mail. I don't know what exactly why you are
against this change, but I'm doubting that it has anything to do with
FSDG compliance.

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

[David Craven]

Either you don't have a case or you are incapable of making one.
Either way don't be a sore looser.

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

[Mathieu Lirzin]

David Craven <david@craven.ch> writes:

>> unless you convince the Guix maintainers that my doubt are not legitimate
>
> I'm sorry but I haven't heard anyone except you express doubt. I made
> several arguments to which you did not respond. Who else except you do
> you think I have to convince? 

I have already express my point.  Please address your arguments to
<gnu-linux-libre@nongnu.org> not to me.

> You made no effort on your part as I explained in the previous mail. I
> don't know what exactly why you are against this change, but I'm
> doubting that it has anything to do with FSDG compliance.

This is your version of the story.  I have tried to explain to you how
the change you have proposed is likely to be related to the "guix build
--source" FSDG issue.  Claiming that I have not made any effort because
you are not convinced is unfair.

-- 
Mathieu Lirzin

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

[Ben Woodcroft]

Hi,


On 10/08/16 22:06, Mathieu Lirzin wrote:
> David Craven <david@craven.ch> writes:

I don't have anything to to contribute beyond psuedo-quoting Ludo: let's 
not lose our hair over this!

ben

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

[David Craven]

>> David Craven <david@craven.ch> writes:

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

So you are telling me that I'm being a jerk? That may well be. If you
want to provide an outline of how to better handle this situation than
I did I'm all ears.

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

[Ben Woodcroft]

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 think it would be good to get further opinions on the technical issue 
at hand, but I'm afraid I don't respect my own enough to contribute it.
ben

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

[David Craven]

> the technical issue at hand

I disagree that it's a technical issue. Technical issues can be
reasoned about and can be fixed. This issue isn't technical.

> I think it would be good to get further opinions on the technical issue at hand

How do we get further opinions on the issue?

> I'm afraid I don't respect my own enough to contribute it

I think this contradicts the first part of the sentence. If no one is
willing to contribute their opinion this issue will get stale.

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

[Ricardo Wurmus]

Ben Woodcroft <b.woodcroft@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?

~~ Ricardo

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

[David Craven]

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

I don't disagree. Alex what do you think?

This is a technical reason to drop the patch. I can live with this no problem.
I just don't like it when I feel someone is serving me BS. But I'm sorry for
getting upset and overreacting.

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

[Alex Kost]

David Craven (2016-08-10 17:13 +0300) wrote:

>> 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.
>
> I don't disagree. Alex what do you think?

Do you mean about your original proposal?  I am for it: I don't
comprehend why the source URL can't be displayed (especially since a
user can easily find it anyway), but I don't understand FSDG well enough
to judge, so I prefer not to participate in this discussion.

(I hope this thread will not tear Guix contributors apart)

-- 
Alex

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

[David Craven]

How invested are you in this patch? I decided that I wasn't that
invested and it isn't worth the trouble. Some things are not meant to
be.

I hate giving Mathieu the satisfaction, since it opens the door to
raising an FSDG issue on any patch, either because you dislike the
patch or the author.

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

[Ricardo Wurmus]

David Craven <david@craven.ch> writes:

> I hate giving Mathieu the satisfaction, since it opens the door to
> raising an FSDG issue on any patch, either because you dislike the
> patch or the author.

Please don’t do this.  This is not constructive.

~~ Ricardo

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

[Alex Kost]

David Craven (2016-08-11 19:19 +0300) wrote:

> How invested are you in this patch? I decided that I wasn't that
> invested and it isn't worth the trouble. Some things are not meant to
> be.

Invested?  Sorry, I don't understand.  Do you mean how much I need this
patch?  Well, I don't need it at all, since I never use "guix package
--show".  I just don't see a problem in accepting this patch as I don't
understand Mathieu's and Mark's concerns about FSDG compliance, but I'm
not competent in this area, so I let other people judge.

-- 
Alex

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

[Ricardo Wurmus]

Alex Kost <alezost@gmail.com> writes:

> David Craven (2016-08-10 17:13 +0300) wrote:
>
>>> 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.
>>
>> I don't disagree. Alex what do you think?
>
> Do you mean about your original proposal?  I am for it: I don't
> comprehend why the source URL can't be displayed (especially since a
> user can easily find it anyway), but I don't understand FSDG well enough
> to judge, so I prefer not to participate in this discussion.

I have previously stated that I’m not convinced that we really need a
serialisation of the “source” field in the user-facing recutils output.
The patch was a welcome demonstration of how this feature would look
like.

As to the question about whether printing the plain upstream source URLs
has FSDG implications I suggest that those who think that this change
would be an improvement bring it up for discussion on the
gnu-linux-libre mailing list, as we don’t want to ignore the concerns
brought up by Mathieu and Mark.

> (I hope this thread will not tear Guix contributors apart)

It won’t :)  I think it’s obvious that there has been some
miscommunication in this thread.  We may be able to avoid this in the
future if everyone made a conscious effort at being courteous when
writing and tolerant when reading.  It is easy to miscommunicate in a
textual medium.

~~ Ricardo

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

[Alex Kost]

Ricardo Wurmus (2016-08-11 19:42 +0300) wrote:

> Alex Kost <alezost@gmail.com> writes:
>
>> David Craven (2016-08-10 17:13 +0300) wrote:
>>
>>>> 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.
>>>
>>> I don't disagree. Alex what do you think?
>>
>> Do you mean about your original proposal?  I am for it: I don't
>> comprehend why the source URL can't be displayed (especially since a
>> user can easily find it anyway), but I don't understand FSDG well enough
>> to judge, so I prefer not to participate in this discussion.
>
> I have previously stated that I’m not convinced that we really need a
> serialisation of the “source” field in the user-facing recutils output.
> The patch was a welcome demonstration of how this feature would look
> like.

Yes, I agree that it's a good demonstration of using Scheme API to get
any package info you need.  But many (probably most) people do not know
Guile and this Guix package API well enough, and for them it may be much
easier to operate on the recutils output of "guix package --show" in
their scripts.  If I understand correctly, that's why David suggested
that patch.

P.S.  I don't want to raise another wave of messages in this thread :-)
If I understand it right, everyone agreed on not merging the patch.

-- 
Alex

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

[Ricardo Wurmus]

Alex Kost <alezost@gmail.com> writes:

> Yes, I agree that it's a good demonstration of using Scheme API to get
> any package info you need.  But many (probably most) people do not know
> Guile and this Guix package API well enough, and for them it may be much
> easier to operate on the recutils output of "guix package --show" in
> their scripts.  If I understand correctly, that's why David suggested
> that patch.

Yes, the recutils output could be used in scripts.  My recommendation
when dealing with source tarballs, however, is to call “guix build -S”
on the package name that recutils provides — this gives the user the
actual corresponding source.  This seems to be sufficient for shell
scripting purposes.

~~ Ricardo

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

[David Craven]

> Invested?  Sorry, I don't understand.

One definition of invest is:
devote (one's time, effort, or energy) to a particular undertaking
with the expectation of a worthwhile result.

I just thought that you had invested some time and energy with this
issue, and don't know what your expectation of a worthwhile result is.
The question was mainly intended to say - I can't be bothered to start
a discussion on a different mailing list, but I'll offer my support if
you think it's worthwhile...

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

[Alex Kost]

David Craven (2016-08-12 13:05 +0300) wrote:

>> Invested?  Sorry, I don't understand.
>
> One definition of invest is:
> devote (one's time, effort, or energy) to a particular undertaking
> with the expectation of a worthwhile result.

Ah, OK, then I'm not invested at all :-)

> I just thought that you had invested some time and energy with this
> issue, and don't know what your expectation of a worthwhile result is.
> The question was mainly intended to say - I can't be bothered to start
> a discussion on a different mailing list, but I'll offer my support if
> you think it's worthwhile...

Thanks, but I wouldn't like to participate in such a discussion.

-- 
Alex

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

[David Craven]

> Thanks, but I wouldn't like to participate in such a discussion.

Yeah, I get the feeling that no one does. That's why saying something
is an FSDG issue is like saying "we won't accept your patch and won't
discuss with you why".

> I just don't see a problem in accepting this patch as I don't
> understand Mathieu's and Mark's concerns about FSDG compliance, but I'm
> not competent in this area, so I let other people judge.

Can you please explain why you don't feel competent? It's written in plain
English, not AES encrypted English, so I have difficulty understanding
why people think they can't read it and form an opinion about it (not this
issue in particular, but more general any issue that comes up), and I don't
just mean you either, but a few people have said this...

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

[Leo Famulari]

On Sat, Aug 13, 2016 at 03:00:42PM +0200, David Craven wrote:
> Can you please explain why you don't feel competent? It's written in plain
> English, not AES encrypted English, so I have difficulty understanding
> why people think they can't read it and form an opinion about it (not this
> issue in particular, but more general any issue that comes up), and I don't
> just mean you either, but a few people have said this...

Personally, after having read it the first time, I wouldn't have
expected web browsers to be excluded from a free distribution due to
their recommendation of non-free "add-ons". I don't disagree with this
interpretation; it simply would not have occurred to me. It requires
some imagination and some time thinking about the issues and the
particularities of the software we use.

So, I think the language of the text and its interpretation are actually
not obvious. And in this case, the point of the patch in question can be
achieved by another method, so I personally didn't want to spend time
interpreting the FSDG when I could spend it on something else.

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

[Alex Kost]

Leo Famulari (2016-08-13 16:18 +0300) wrote:

> On Sat, Aug 13, 2016 at 03:00:42PM +0200, David Craven wrote:
>> Can you please explain why you don't feel competent? It's written in plain
>> English, not AES encrypted English, so I have difficulty understanding
>> why people think they can't read it and form an opinion about it (not this
>> issue in particular, but more general any issue that comes up), and I don't
>> just mean you either, but a few people have said this...
>
> Personally, after having read it the first time, I wouldn't have
> expected web browsers to be excluded from a free distribution due to
> their recommendation of non-free "add-ons". I don't disagree with this
> interpretation; it simply would not have occurred to me. It requires
> some imagination and some time thinking about the issues and the
> particularities of the software we use.
>
> So, I think the language of the text and its interpretation are actually
> not obvious. And in this case, the point of the patch in question can be
> achieved by another method, so I personally didn't want to spend time
> interpreting the FSDG when I could spend it on something else.

Oof, thanks for this message!  I have a similar point.  I always find it
hard to read and understand such (long and boring) guidelines, licenses,
etc.  I realize they are important, but I just don't like to spend my
time on them.

TBH I stopped reading after "These guidelines are not complete" phrase :-)

-- 
Alex

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

[Thompson, David]

On Wed, Aug 10, 2016 at 9:42 AM, Ricardo Wurmus <rekado@elephly.net> wrote:
>
> Ben Woodcroft <b.woodcroft@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

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

[Leo Famulari]

On Wed, Aug 10, 2016 at 10:15:52PM +1000, Ben Woodcroft wrote:
> I don't have anything to to contribute beyond psuedo-quoting Ludo: let's not
> lose our hair over this!

+1

I think our presence on this mailing list shows that we all have a
common goal: the creation and continued improvement of a free software
distribution and operating system.

For practical reasons, I think that we need to try our best to interpret
each others' messages charitably.

Communicating tone and emotion through the English language is hard
enough for those of us who learned it as our first language. There are a
handful of professional writers who have mastered this art, and they
earn a lot of money for it.

The rest of us, myself included, have to accept that we will sometimes
be misinterpreted, and that we will sometimes misinterpret others. So, I
hope we can remember our common goal, give the benefit of the doubt, and
try to let perceived slights slide, since they may not have even been
intended in the first place. Like I said, communicating tone effectively
through written language is very hard, at least with English.

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

[Mark H Weaver]

Mathieu Lirzin <mthl@gnu.org> writes:

> David Craven <david@craven.ch> writes:
>
>> Quoting FSDG:
>> A free system distribution must not steer users towards obtaining any
>> nonfree information for practical use, or encourage them to do so.
>>
>> We are not steering or encouraging users to do any thing by displaying
>> the source url of the tarball, 
>
> That's an interpretation of it.  I think that point deserves a
> discussion on <gnu-linux-libre@nongnu.org> mailing list, before
> including such change in Guix UI.

I agree with Mathieu.  Having the Guix UI display a source URI that
contains non-free software is arguably steering users towards obtaining
nonfree information for practical use.

We will need to ask for input from <gnu-linux-libre@nongnu.org> before
considering this.

> Asking me to start a discussion on the linux-libre mailing list over
> this is an unreasonable request.

I'm sorry that you feel that way, but I'm afraid I must block this
proposed change until that discussion occurs.

       Mark

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

[Mark H Weaver]

Mark H Weaver <mhw@netris.org> writes:

> Mathieu Lirzin <mthl@gnu.org> writes:
>
>> David Craven <david@craven.ch> writes:
>>
>>> Quoting FSDG:
>>> A free system distribution must not steer users towards obtaining any
>>> nonfree information for practical use, or encourage them to do so.
>>>
>>> We are not steering or encouraging users to do any thing by displaying
>>> the source url of the tarball, 
>>
>> That's an interpretation of it.  I think that point deserves a
>> discussion on <gnu-linux-libre@nongnu.org> mailing list, before
>> including such change in Guix UI.
>
> I agree with Mathieu.  Having the Guix UI display a source URI that
> contains non-free software is arguably steering users towards obtaining
> nonfree information for practical use.
>
> We will need to ask for input from <gnu-linux-libre@nongnu.org> before
> considering this.

Sorry, I made a quoting error in my previous message.  The next two
lines were actually written by David, although my quoting made them
appear to be from Mathieu:

>> Asking me to start a discussion on the linux-libre mailing list over
>> this is an unreasonable request.
>
> I'm sorry that you feel that way, but I'm afraid I must block this
> proposed change until that discussion occurs.
>
>        Mark

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

[David Craven]

Hi Mark,

We already agreed to drop the patch. I don't understand why you'd want
to pick a fight that no one is fighting. Besides where the tarball
came from is a fact.

Since this is a point of disagreement I think this is a discussion
that should be had.

I'll provide a couple of word definitions from the English dictionary
before providing my argument so that it is clear what I'm talking
about.

Fact:
1. a thing that is known or proved to be true.
2. information used as evidence or as part of a report or news article.
3. used to refer to a particular situation under discussion.
4. the truth about events as opposed to interpretation.

Inform:
1. give (someone) facts or information
2. give an essential or formative principle or quality to

Steer:
1. guide or control the movement of (a vehicle, vessel, or aircraft),
for example by turning a wheel or operating a rudder.

Are you saying that the source-uri of a package isn't a fact?

If we agree that it is a fact, it can per definition only inform users
actions, being a truth, but not steer them.

The only way that this could be considered steering is as I stated
earlier, if we censor some facts and display others. This causes facts
to show a distorted picture. I provided a solution to this, by
agreeing that we weren't providing all information.

David

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

[Mark H Weaver]

David Craven <david@craven.ch> writes:
> We already agreed to drop the patch.

I didn't know that when I wrote my message, because I hadn't finished
reading the thread.

> Since this is a point of disagreement I think this is a discussion
> that should be had.

Having now read the entire thread, I'd prefer not to discuss this
further with you, but if you insist, please raise it on
<gnu-linux-libre@nongnu.org>, not here.

      Mark

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

[David Craven]

I expect someone to calmly and rationally reply to my argument and
take it seriously, I don't think it's to big of an ask. I want this
discussion to find a resolution.

>> Asking me to start a discussion on the linux-libre mailing list over
>> this is an unreasonable request.

> I'm sorry that you feel that way, but I'm afraid I must block this
> proposed change until that discussion occurs.

I agreed to contribute to guix, participate constructively in
discussions and actively try to find agreement.

What I did not sign up for is recognizing a third party authority like
the <gnu-linux-libre@nongnu.org> and asking them for permission for
small changes. Who made them the FSDG police? (This is a calm question
even if it may not sound that way...)

Re: How to get the package metadata as structured data?

[Ricardo Wurmus]

Philippe Ombredanne <pombredanne@nexb.com> writes:

> David Craven <david@craven.ch> wrote:
>> I aborted, since I realised that guix package -s doesn't include the
>> source url and hash, which would be important for a testsuite...
>
> IMHO, if the rec data is the only way to get to the packages data, the
> source url would be rather essential to get in.

The recutils output is not the *only* way to access the package data.
All packages in Guix are just Scheme variables.  Package data are
available as S-expressions and can be read by Scheme programs or parsed
by external applications.  The recutils output is just an additional
format used when interacting with Guix on the command line.

(Personally, I’m not enthusiastic about adding a serialised form of the
source field to the recutils output.)

~~ Ricardo

Re: How to get the package metadata as structured data?

[Catonano]

[-- Attachment #1: Type: text/plain, Size: 1302 bytes --]

2016-08-10 13:46 GMT+02:00 Ricardo Wurmus <rekado@elephly.net>:

>
> Philippe Ombredanne <pombredanne@nexb.com> writes:
>
> > David Craven <david@craven.ch> wrote:
> >> I aborted, since I realised that guix package -s doesn't include the
> >> source url and hash, which would be important for a testsuite...
> >
> > IMHO, if the rec data is the only way to get to the packages data, the
> > source url would be rather essential to get in.
>
> The recutils output is not the *only* way to access the package data.
> All packages in Guix are just Scheme variables.  Package data are
> available as S-expressions and can be read by Scheme programs or parsed
> by external applications.  The recutils output is just an additional
> format used when interacting with Guix on the command line.
>
> (Personally, I’m not enthusiastic about adding a serialised form of the
> source field to the recutils output.)
>
> ~~ Ricardo
>
>
>
Not so long ago, someone posted a script that produced a web page with the
results of linting all the packages

That's an example

One could produce an xml file to be imported in Gephi, just to make another
example.

Or a SQL text file to be imported in some relational db, or a different
format to be imported in some not relational db...

[-- Attachment #2: Type: text/html, Size: 1978 bytes --]

Re: How to get the package metadata as structured data?

[Ricardo Wurmus]

Catonano <catonano@gmail.com> writes:

> 2016-08-10 13:46 GMT+02:00 Ricardo Wurmus <rekado@elephly.net>:
>
>>
>> Philippe Ombredanne <pombredanne@nexb.com> writes:
>>
>> > David Craven <david@craven.ch> wrote:
>> >> I aborted, since I realised that guix package -s doesn't include the
>> >> source url and hash, which would be important for a testsuite...
>> >
>> > IMHO, if the rec data is the only way to get to the packages data, the
>> > source url would be rather essential to get in.
>>
>> The recutils output is not the *only* way to access the package data.
>> All packages in Guix are just Scheme variables.  Package data are
>> available as S-expressions and can be read by Scheme programs or parsed
>> by external applications.  The recutils output is just an additional
>> format used when interacting with Guix on the command line.
>>
>> (Personally, I’m not enthusiastic about adding a serialised form of the
>> source field to the recutils output.)
>>
>> ~~ Ricardo
>>
>>
>>
> Not so long ago, someone posted a script that produced a web page with the
> results of linting all the packages
>
> That's an example
>
> One could produce an xml file to be imported in Gephi, just to make another
> example.
>
> Or a SQL text file to be imported in some relational db, or a different
> format to be imported in some not relational db...

I understand that it may be useful.  I just think that the
representation as a Guile Scheme expression/value is *already* much more
useful.  That’s what made “guix web” possible, a web interface like this
one:

    http://guix.mdc-berlin.de

Producing other formats (such as XML files) is also quite simple.  The
package expression itself is *executable*.  By overriding the meaning of
the executable parts one could easily evaluate the expression such that
it generates some other format.

~~ Ricardo

Re: How to get the package metadata as structured data?

[Catonano]

[-- Attachment #1: Type: text/plain, Size: 2380 bytes --]

2016-08-10 14:52 GMT+02:00 Ricardo Wurmus <rekado@elephly.net>:

>
> Catonano <catonano@gmail.com> writes:
>
> > 2016-08-10 13:46 GMT+02:00 Ricardo Wurmus <rekado@elephly.net>:
> >
> >>
> >> Philippe Ombredanne <pombredanne@nexb.com> writes:
> >>
> >> > David Craven <david@craven.ch> wrote:
> >> >> I aborted, since I realised that guix package -s doesn't include the
> >> >> source url and hash, which would be important for a testsuite...
> >> >
> >> > IMHO, if the rec data is the only way to get to the packages data, the
> >> > source url would be rather essential to get in.
> >>
> >> The recutils output is not the *only* way to access the package data.
> >> All packages in Guix are just Scheme variables.  Package data are
> >> available as S-expressions and can be read by Scheme programs or parsed
> >> by external applications.  The recutils output is just an additional
> >> format used when interacting with Guix on the command line.
> >>
> >> (Personally, I’m not enthusiastic about adding a serialised form of the
> >> source field to the recutils output.)
> >>
> >> ~~ Ricardo
> >>
> >>
> >>
> > Not so long ago, someone posted a script that produced a web page with
> the
> > results of linting all the packages
> >
> > That's an example
> >
> > One could produce an xml file to be imported in Gephi, just to make
> another
> > example.
> >
> > Or a SQL text file to be imported in some relational db, or a different
> > format to be imported in some not relational db...
>
> I understand that it may be useful.  I just think that the
> representation as a Guile Scheme expression/value is *already* much more
> useful.  That’s what made “guix web” possible, a web interface like this
> one:
>
>     http://guix.mdc-berlin.de



Yes, Ricardo, I was not disagreeing with you. I was just trying to offer
Philippe some more perspective.

In fact I believe that the approach you envisioned (a cycle through the
packages values, leaving only the decompress phase and adding a phase that
calls Philippe's tool) has its merits.

Only, if I was Philippe, I would regret storing the output in the store

I'd prefer to be able to store the output in the regular file system

In this regard, I think that the threads about pipelines (for reproducible
science), some time ago, were quite interesting

[-- Attachment #2: Type: text/html, Size: 3353 bytes --]