guix-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Outreachy - Guix Data Service: implementing basic json output for de


From: Christopher Baines
Subject: Re: Outreachy - Guix Data Service: implementing basic json output for derivation comparison page
Date: Sun, 18 Apr 2021 17:34:13 +0100
User-agent: mu4e 1.4.15; emacs 27.1

Luciana Lima Brito <lubrito@posteo.net> writes:

> Hi,
>
> On Sat, 17 Apr 2021 18:45:14 +0100
> Christopher Baines <mail@cbaines.net> wrote:
>
>> Some more things to think about:
>>
>>  - Variable naming, what does the "matched" in matched outputs mean?
>>    (same goes for the other "matched" things)
>
> The name matched would refer to the match function, but I changed to
> *-values. The names I wanted were "outputs", "inputs"
> and "sources", but I already used them. If you have anything in mind,
> please let me know.

I think it might be good to do something, just to narrow the scope. The
outputs binding is valid for the whole let*, and all the code in it, but
is only used on three lines, in one single place. Maybe there could be a
let there that just defines outputs (maybe named output-groups so you
can use the outputs binding for the overall thing).

>>  - (if (null? ...), I'm unsure if all of those checks are necessary, I
>>    believe some fields at least will never be "null?".
>
> I revised it, I think now it's better.
> About the "recursive" field, apparently it assumes a string value "t"
> or "f", and I convert this to a boolean. Are there other values
> possible?

That's a good question, I'd look at the database schema, assuming the
type of the field is a boolean, the question is whether the field is
nullable?

>> I think you're getting close to something that's ready to merge
>> though.
>
> One last thing, I see that on the html the commom inputs are ommited.
> Does this make sense for the json too?

Hmm, I'm not sure why that is on the HTML page, but I'd generally try
and keep most bits in the JSON, since it's not as helpful to omit bits
if they're not that important.

One other thing I noticed is that the alist for the args is being picked
apart then reconstructed. Like for the inputs, outputs and sources, I'd
map over the arguments alist and transform it to the way you want it to
be.

Attachment: signature.asc
Description: PGP signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]