+1 for (ice-9 base64) On Wed, Aug 17, 2022, 02:04 Maxime Devos <maximede...@telenet.be> wrote:
> > On 16-08-2022 19:21, Aleix Conchillo Flaqué wrote: > > > > On Tue, Aug 16, 2022 at 9:59 AM Maxime Devos <maximede...@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. >
