Re: (ice-9 base64)?

[Blake Shaw <blake@sweatshoppe.org>]

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

+1 for (ice-9 base64)

On Wed, Aug 17, 2022, 02:04 Maxime Devos <maximedevos@telenet.be> wrote:

>
> 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.
>

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