all messages for Guix-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Jelle Licht <jlicht@fsfe.org>
To: guix-devel <guix-devel@gnu.org>
Subject: Maintaining implementations of similar utility functions like json-fetch
Date: Fri, 26 Jan 2018 16:28:28 +0100	[thread overview]
Message-ID: <CAPsKtf+w=g15EHAhWqgw+2BqwPW581JzbsvxkGGOTu8wNx1T3g@mail.gmail.com> (raw)

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

Hello!

I noticed that there are currently two very similar functions for fetching
json data; `json-fetch' in (guix import json) and `json-fetch*' in (guix
import github).

Some things I noticed:
- Dealing with http error codes seems to be a bit more robust in
`json-fetch*'.
- Making sure that (compliant) servers give responses in the proper format
seems more robust in `json-fetch' due to using Accept headers.
- Dealing with the fact that json responses are technically allowed to be
lists of objects, which `json-fetch' does not handle gracefully.

For this issue specifically, would it make sense to combine the two
definitions into a more general one?

My more general concern would be on how we can prevent bug fixes only being
applied to one of several nearly identical functions. IOW, should we try to
prevent situations like this from arising, or is it okay if we somehow make
sure that fixes should be applied to both locations?

-- 
Jelle

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

             reply	other threads:[~2018-01-26 15:28 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-01-26 15:28 Jelle Licht [this message]
2018-01-27 16:09 ` Maintaining implementations of similar utility functions like json-fetch Ludovic Courtès
2018-01-31 17:32   ` Jelle Licht
2018-02-01 11:54     ` Catonano
2018-02-01 12:14       ` Gábor Boskovits
2018-02-05 13:12     ` Ludovic Courtès
2018-02-05 14:51       ` Alex Vong
2018-06-10 18:50       ` Jelle Licht
2018-06-10 19:54         ` Ludovic Courtès

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='CAPsKtf+w=g15EHAhWqgw+2BqwPW581JzbsvxkGGOTu8wNx1T3g@mail.gmail.com' \
    --to=jlicht@fsfe.org \
    --cc=guix-devel@gnu.org \
    /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.