all messages for Guix-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Christopher Baines <mail@cbaines.net>
To: Luciana Lima Brito <lubrito@posteo.net>
Cc: guix-devel@gnu.org
Subject: Re: Guix Data Service - Outreachy: questions about render-compare/derivation
Date: Mon, 12 Apr 2021 20:41:18 +0100	[thread overview]
Message-ID: <87sg3vz3xd.fsf@cbaines.net> (raw)
In-Reply-To: <20210412121425.628b8260@lubrito>

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


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

> I'm lubrito on Guix IRC, the Outreachy applicant.
>
> I'm working on the json output for the render-compare/derivation
> procedure (controller.scm).

Hi lubrito,

Good to hear from you.

> I would like to know if I am on the right path with what I've
> accomplished until now.

You've got some JSON being rendered, so you're definitely on the right
path :)

> The attached .ppm file shows the json I have so far. The json is
> showing only the data for the "outputs", but I already got the data for
> the rest and I could do the same to them. I am still thinking about how
> to make the code cleaner, because the way I'm doing could produce many
> redundancies.
>
> I also would like to know if the general structure of the json is
> correct or if it should be different. For example, under "outputs" "0"
> is denoting base and "1" is denoting target.
>
> The current code for the function is here http://sprunge.us/mKkzX2

So, there's no "correct" structure for the JSON, but some structures
might better represent the data than others, there's a number of factors
to balance.

I think an object with base and target names would easier to understand
than using an array.

Some of the types in the JSON are a bit off as well, part of this is the
query processing is not working quite right, but that's a different
issue. For the JSON you've got so far, I'd specifically look at the
hash, hash-algorithm and recursive fields. hash and hash-algorithm are
only set for some outputs (only for fixed output derivations), it would
probably be better to have these fields set to null if they don't have a
string value, or not included in the object. For recursive, that's a
boolean, so it should be a boolean in the JSON too.

Hope that helps!

Chris

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 987 bytes --]

  reply	other threads:[~2021-04-12 19:41 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-04-12 15:14 Guix Data Service - Outreachy: questions about render-compare/derivation Luciana Lima Brito
2021-04-12 19:41 ` Christopher Baines [this message]
2021-04-13 19:45   ` Luciana Lima Brito
2021-04-13 21:06     ` Christopher Baines

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87sg3vz3xd.fsf@cbaines.net \
    --to=mail@cbaines.net \
    --cc=guix-devel@gnu.org \
    --cc=lubrito@posteo.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/guix.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.