From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jelle Licht Subject: Maintaining implementations of similar utility functions like json-fetch Date: Fri, 26 Jan 2018 16:28:28 +0100 Message-ID: Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="001a1144096857fe1c0563af8ca2" Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:46774) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ef5vf-00069n-7j for guix-devel@gnu.org; Fri, 26 Jan 2018 10:28:36 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ef5ve-0000UB-0s for guix-devel@gnu.org; Fri, 26 Jan 2018 10:28:35 -0500 Received: from mail.fsfe.org ([2001:aa8:ffed::3:102]:40603) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1ef5vd-0000TK-OE for guix-devel@gnu.org; Fri, 26 Jan 2018 10:28:33 -0500 Received: from localhost (localhost [127.0.0.1]) by mail.fsfe.org (Postfix) with ESMTP id 4EAA963BC3E for ; Fri, 26 Jan 2018 16:28:31 +0100 (CET) Received: from mail.fsfe.org ([127.0.0.1]) by localhost (cavendish.fsfeurope.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kpd4ilH0vN0C for ; Fri, 26 Jan 2018 16:28:31 +0100 (CET) Received: by mail-vk0-f49.google.com with SMTP id m197so498736vka.3 for ; Fri, 26 Jan 2018 07:28:30 -0800 (PST) List-Id: "Development of GNU Guix and the GNU System distribution." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-devel-bounces+gcggd-guix-devel=m.gmane.org@gnu.org Sender: "Guix-devel" To: guix-devel --001a1144096857fe1c0563af8ca2 Content-Type: text/plain; charset="UTF-8" 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 --001a1144096857fe1c0563af8ca2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello!
I noticed that there are currently two very similar functions for fe= tching json data; `json-fetch' in (guix import json) and `json-fetch*&#= 39; in (guix import github).

Some things I noticed:
= - Dealing with http error codes seems to be a bit more robust in `json-fetc= h*'.
- 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 technica= lly allowed to be lists of objects, which `json-fetch' does not handle = gracefully.

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

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

--
Jelle
--001a1144096857fe1c0563af8ca2--