Re: (ice-9 base64)?

[Maxime Devos]

On 16-08-2022 19:21, Aleix Conchillo Flaqué wrote:

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

On 16-08-2022 18:10, Aleix Conchillo Flaqué wrote:

Hi,

In many projects I've been copying Göran Weinholt's base64 implementation and I've also seen 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 help here? :-) ).  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/f8934ec94df5868ee8baf1fb0f8ed0f24e7e91eb

    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. 
    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 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])).  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.  Guix 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 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.

OpenPGP_0x49E3EE22191725EE.asc
Description: OpenPGP public key

OpenPGP_signature
Description: OpenPGP digital signature