Catonano <caton...@gmail.com> writes:
> 2016-08-10 13:46 GMT+02:00 Ricardo Wurmus <rek...@elephly.net>:
>
>>
>> Philippe Ombredanne <pombreda...@nexb.com> writes:
>>
>> > David Craven <da...@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
