From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp12.migadu.com ([2001:41d0:2:bcc0::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms5.migadu.com with LMTPS id cIoAI/oc/GKuuQAAbAwnHQ (envelope-from ) for ; Wed, 17 Aug 2022 00:40:58 +0200 Received: from aspmx1.migadu.com ([2001:41d0:2:bcc0::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp12.migadu.com with LMTPS id YKX1Ivoc/GKqwQAAauVa8A (envelope-from ) for ; Wed, 17 Aug 2022 00:40:58 +0200 Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by aspmx1.migadu.com (Postfix) with ESMTPS id 367D5E926 for ; Wed, 17 Aug 2022 00:40:58 +0200 (CEST) Received: from localhost ([::1]:33380 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1oO5F3-0003qI-CV for larch@yhetil.org; Tue, 16 Aug 2022 18:40:57 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:36018) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oO5Eo-0003pv-07 for guix-devel@gnu.org; Tue, 16 Aug 2022 18:40:42 -0400 Received: from mail-ej1-x631.google.com ([2a00:1450:4864:20::631]:43896) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1oO5El-0006O8-Mc for guix-devel@gnu.org; Tue, 16 Aug 2022 18:40:41 -0400 Received: by mail-ej1-x631.google.com with SMTP id gb36so21508063ejc.10 for ; Tue, 16 Aug 2022 15:40:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sweatshoppe-org.20210112.gappssmtp.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc; bh=hx0jgwYIoyo9g9fKdjAS9F5hqKmWfzmjW5EYgpz8sDc=; b=7ZqMiYkRLz+b4HhRVlq28kcKmz012FC9Uwdj1JVVwWyhkB4c6XJG1OWfmpbfFJUHS+ mRt1uOF/fI67cU2D9qwW7JntK5dUwyqXIrKtBAe1AXckaOFXVjJjBqI3DC4JhRT9Vwqn 0YFHxZYXEbRKfs/wl5BetXze5nsNaOy1aZvznrUZbAW+3qCr3k+h9fAnmkbivbuemX24 76nH0KtX4CCW4aJUp+SM4cTXI90jtDEwsK2hXvChZmjdVTRU4mB82YQaUb+K7y7f8u2+ mqjHt8KjCA30Zk8BOGXwg68xsrznJtgEXr1JKbrXzr60iJI1zldH6p+s1kfBFCTNQyyI bkMA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc; bh=hx0jgwYIoyo9g9fKdjAS9F5hqKmWfzmjW5EYgpz8sDc=; b=Ac8PduZywYBqYTE/UV2sjOWjQEIQgThER5EwwV4moJ6Gr9frbPnJbdOPrw89RgCJwa Po5steJ5/HqY5eoklciyaeRttNk5/lUuVu/Vm47c31rnDq9chZ9y7LqyJWbY0Nwzkp0x TxqmHxPtUzMS4ggHqk0OyacZf0Not2L4tP2M9fPeJsMEUoB7XmyBBR2TE6iEOkTrHD1h Kpyz0FEQbvPlRVL74g98BXQ9mkfTJJjasqySS3VuZWvKmFEV8pGyC1GzO1YOeLJza40w Y0hsMGHAfIoohfUvgq7pILpWzMdp5ZDE1Nc2q+qbTmrpAMsukrp08hDGQ7WDl/suaLAs 7unA== X-Gm-Message-State: ACgBeo2U+21pcMrWYH4iUKcMd+3fZ8lmi66vNtBKDsNrBLT2g9YyT/Qh 9YTG59NO2LpEnZWseNkAcnF16VPZkMBd1or4BjQS1OBJpZCU1A== X-Google-Smtp-Source: AA6agR60Yyhlt4UGzWKd2za72nIIXvE68b588q9pVDqbTPn3KsK01VOrwByKwjIjEpvgN8PQyuh51X53e8Tx9j4dNVI= X-Received: by 2002:a17:907:7b94:b0:731:1b11:c241 with SMTP id ne20-20020a1709077b9400b007311b11c241mr15013857ejc.676.1660689636628; Tue, 16 Aug 2022 15:40:36 -0700 (PDT) MIME-Version: 1.0 References: <33556713-c85b-ab0f-554e-94a40f9d418e@telenet.be> In-Reply-To: From: Blake Shaw Date: Wed, 17 Aug 2022 05:40:24 +0700 Message-ID: Subject: Re: (ice-9 base64)? To: Guix-devel Cc: =?UTF-8?Q?Aleix_Conchillo_Flaqu=C3=A9?= Content-Type: multipart/alternative; boundary="000000000000dfb84105e6636fba" Received-SPF: none client-ip=2a00:1450:4864:20::631; envelope-from=blake@sweatshoppe.org; helo=mail-ej1-x631.google.com X-Spam_score_int: -18 X-Spam_score: -1.9 X-Spam_bar: - X-Spam_report: (-1.9 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: guix-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list 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+larch=yhetil.org@gnu.org Sender: "Guix-devel" X-Migadu-Flow: FLOW_IN X-Migadu-To: larch@yhetil.org X-Migadu-Country: US ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1660689658; h=from:from:sender:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:in-reply-to:in-reply-to: references:references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:dkim-signature; bh=hx0jgwYIoyo9g9fKdjAS9F5hqKmWfzmjW5EYgpz8sDc=; b=fKRSAD4GSKdmTaO3fV9D5+1Qadpq0uqR7EAOLo3U1bngwm+QSWOgrw63IRmNxSsokhCJoN YrDWcjBmZnSk5DZNsopdZKEd0XmRMFadJ1zTp70u1avuvTtN+7CqVsDfEUitWyarFttx9v fBtRcXXlIjsMKo2rsV6AYrUdpPETRfDk2YPn/t0Q+P9lv8Kpofz9pUWSigqURgR4d/jJuT r9d8j/gcFuh6coFlr5rbVzvGNtiMeH0cYplUNgPg/SheiWAvaPPviX6/on7M/yYBls2jol GZg0dDDIksN7Yy6nu9qVVgRPMPT6F4vGOcmGpgbDLuqnVid//EXuBNY5SJOAzQ== ARC-Seal: i=1; s=key1; d=yhetil.org; t=1660689658; a=rsa-sha256; cv=none; b=CKYAPBuCENLUsOCQtO8dxoAYAAZwThjZ9LxMFE+8p+FhZS2mZ+Rvhh/BvW+FF6GjkjTnLk 5UljkZmpL8A8an14Q8/VlvR7PFA28d+035wjZn+D3cOUrVCFkIhPwUAfFgQcQAi6cR3474 vJLcryEV4S6ZSGzxzZc16nt8ZGeEbclVpWZSkBb9dkgD5AV1zk5gX/T7jTJB4Znn9zRpQ1 S0eNqdtlMKrKu0auFD+I86xg5KMKxgE/GW8g1c/NZYJigN2g72OBio31hgyPjODD131fnf scarGTa5XlUA66pPIHmzIJK1G2SzqebEOgptvZJ9nhbEO+8VZS+cJdPDHL4JIw== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=pass header.d=sweatshoppe-org.20210112.gappssmtp.com header.s=20210112 header.b=7ZqMiYkR; dmarc=none; spf=pass (aspmx1.migadu.com: domain of "guix-devel-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="guix-devel-bounces+larch=yhetil.org@gnu.org" X-Migadu-Spam-Score: -2.36 Authentication-Results: aspmx1.migadu.com; dkim=pass header.d=sweatshoppe-org.20210112.gappssmtp.com header.s=20210112 header.b=7ZqMiYkR; dmarc=none; spf=pass (aspmx1.migadu.com: domain of "guix-devel-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="guix-devel-bounces+larch=yhetil.org@gnu.org" X-Migadu-Queue-Id: 367D5E926 X-Spam-Score: -2.36 X-Migadu-Scanner: scn1.migadu.com X-TUID: cc9FqVOqtCJs --000000000000dfb84105e6636fba Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable +1 for (ice-9 base64) On Wed, Aug 17, 2022, 02:04 Maxime Devos wrote: > > On 16-08-2022 19:21, Aleix Conchillo Flaqu=C3=A9 wrote: > > > > On Tue, Aug 16, 2022 at 9:59 AM Maxime Devos > wrote: > >> >> On 16-08-2022 18:10, Aleix Conchillo Flaqu=C3=A9 wrote: >> >> Hi, >> >> In many projects I've been copying G=C3=B6ran Weinholt's base64 >> implementation and I've also seen it in other projects, would it make se= nse >> to include it in Guile's standard library? [...] >> >> If we do this, we should contact the various other projects to make them >> use (ice-9 base64). >> > > I think they could switch whenever they want (i.e. whenever this was adde= d > to Guile) or even not switch at all. > > Sure, but they can't switch if they don't know about it. And if they don'= t > know about it and hence don't switch, the proposal fails at its purpose o= f > unbundling base64. Besides, we need them to switch (see Guix no-bundling > policy and the reasons behind it) -- if upstream refuses to unbundle, the= n > in our locally modified version for Guix. > > I think it would be simpler though to consider the base64 in guile-gcrypt >> to be 'canonical', it would avoid problems with old versions of Guile no= t >> having the base64 module and newer version having it, which would preven= t >> using the proposed (ice-9 base64) in Guile because it would break >> build-aux/build-self.scm when pulling or time-machining from old Guix th= at >> have an old Guile. >> > > I've been waiting on a guile-gcrypt release for a while now (Ludo, > Chrisitine... any help here? :-) ). I ported guile-jwt to use guile-gcry= pt > but I need a release to have latest base64 changes: > > > https://notabug.org/cwebber/guile-gcrypt/commit/f8934ec94df5868ee8baf1fb0= f8ed0f24e7e91eb > > Right, it has some fixes that are presumably important. > > > But you are right that this would cause a backward compatible problem, bu= t > I guess that would depend on each project. Can we do conditional module > loading? I've done this in the past with Python... if we are in Python 2 > load this module, otherwise load this other one. So projects could do tha= t. > > Yes, using resolve-module with #:ensure #f & module-ref. Or with syntax > tricks and (version), to decide things at compile-time. Still, if you do= a > conditional module loading, you still need a fallback, and the fallback > would still be bundling. > > Whether we simply replace (guix base64) by (gcrypt base64) depends on how >> old (gcrypt base64) is compared to the earliest 'supported' Guix for >> pull/time-travel, but even if it is not present in the old gcrypt, we ca= n >> work-around that (we have a 'fake-gcrypt-hash' in build-aux/build-self.s= cm, >> so we can easily have a (define gcrypt-base64 [some copy])). Or simply >> update the local guile-gcrypt in buid-aux/build-self.scm. >> > guile-gcrypt base64 is pretty new with the patch above (but no release > after that), I have no idea if Guix has added anything else. > > base64 is available in at least 0.3.0, which is packaged in Debian > bullseye (which is considered "stable"), so not too new, though we might > need to change build-aux/build-self.scm if 0.1.0 doesn't have base64. Gu= ix > appears to have the pre-quoted-patch version, without changes of its own > except for a different module name. > > OTOH a similar replacement can be done for (ice-9 base64), but >> transitioning to (ice-9 base64) would take much longer, at least until t= he >> various distributions are updated to a Guile that has (ice-9 base64), >> whereas (gcrypt base64) could be switched to immediately. >> > Maybe this could be handled by each project independently. > > They wouldn't have to if the base64 module is put in (guile gcrypt). > > Greetings, > Maxime. > --000000000000dfb84105e6636fba Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
+1 for (ice-9 base64)

On Wed, Aug 17, 2022, 02:04 Maxime D= evos <maximedevos@telenet.be> wrote:
=20 =20 =20


On 16-08-2022 19:21, Aleix Conchillo Flaqu=C3=A9 wrote:
=20


On Tue, Aug 16, 2022 at 9:5= 9 AM Maxime Devos <maximedevos@telenet.be> wrote:


On 16-08-2022 18:10, Aleix Conchillo Flaqu=C3=A9 wrote:<= br>
Hi,

In many projects I've been copying G=C3=B6ran Weinholt's base64 implementation and I've also se= en it in other projects, would it make sense to include it in Guile's standard library? [...]

If we do this, we should contact the various other projects to make them use (ice-9 base64).


I think they could switch whenever they want (i.e. whenever this was added to Guile) or even not switch at all.

Sure, but they can't switch if they don't know about it. And= if they don't know about it and hence don't switch, the proposal fails at its purpose of unbundling base64. Besides, we need them to switch (see Guix no-bundling policy and the reasons behind it) -- if upstream refuses to unbundle, then in our locally modified version for Guix.

I think it would be simpler though to consider the base64 in guile-gcrypt to be 'canonical', it would = avoid problems with old versions of Guile not having the base64 module and newer version having it, which would prevent using the proposed (ice-9 base64) in Guile because it would break build-aux/build-self.scm when pulling or time-machining from old Guix that have an old Guile.


I've been waiting on a guile-gcrypt release for a while now (Ludo, Chrisitine... any=C2=A0help here? :-) ).=C2=A0 I ported guile= -jwt to use guile-gcrypt but I need a release to have latest base64 changes:

https://notabug.org/cwebber/guile-gcrypt/commit/f8934ec94df5868ee8baf1fb0f= 8ed0f24e7e91eb
Right, it has some fixes that are presumably important.

But you are right that this would cause a backward compatible problem, but I guess that would depend on each project. Can we do conditional module loading? I've done this in the past with Python... if we are in Python 2 load this module, otherwise load this other one. So projects could do that.
Yes, using resolve-module with #:ensure #f & module-ref. Or with syntax tricks and (version), to decide things at compile-time.=C2=A0 Still, if you do a conditional module loading, you still need a fallback, and the fallback would still be bundling.

Whether we simply replace (guix base64) by (gcrypt base64) depends on how old (gcrypt base64) is compared to the earliest 'supported' Guix for pull/time-trav= el, but even if it is not present in the old gcrypt, we can work-around that (we have a 'fake-gcrypt-hash' in build-aux/build-self.scm, so we can easily have a (define gcrypt-base64 [some copy])).=C2=A0 Or simply update the local guile-gcrypt in buid-aux/build-self.scm.

guile-gcrypt base64 is pretty new with the patch above (but no release after that), I have no idea if Guix has added anything else.

base64 is available in at least 0.3.0, which is packaged in Debian bullseye (which is considered "stable"), so not too = new, though we might need to change build-aux/build-self.scm if 0.1.0 doesn't have base64.=C2=A0 Guix appears to have the pre-quoted-pa= tch version, without changes of its own except for a different module name.

OTOH a similar replacement can be done for (ice-9 base64), but transitioning to (ice-9 base64) would take much longer, at least until the various distributions are updated to a Guile that has (ice-9 base64), whereas (gcrypt base64) could be switched to immediately.

Maybe this could be handled by each project independently.

They wouldn't have to if the base64 module is put in (guile gcrypt).

Greetings,
Maxime.

--000000000000dfb84105e6636fba--