Hi Maxime! On Tue, Aug 16, 2022 at 12:04 PM 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. > Forgive my ignorance, but what do you mean by unbundling? I'm not familiar with Guix at all, well, just conceptually and for trying a few commands years ago. > > 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. > Cool, thanks! Again, I need a description for unbundling :-(. > 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. > One more time, forgive me, but what is build-aux/build-self.scm? > 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). > > > And the last forgiveness... (guile gcrypt)? Aleix
