Thank you for the explanations Maxime! Then, if I understood correctly, IMO I would say Guile should not really care about Guix's bundling/unbundling. That is, adding (ice-9 base64) (or however we want to call it... maybe (encoding base64) following Golang and Guile's (web ....) module) should be totally independent of Guix. So, if we add (ice-9 base64) to Guile then Guix should figure out what to do with it, but it's Guix's concern not Guile's. About Guix's unbundling (maybe that's something that should go on Guix's mailing list), I don't think currently there's any unbundling for base64 modules or at least not in a package I maintain guile-jwt (guile-jwt bundles base64). And probably there's no unbundling because there's no canonical implementation? Even if there was a canonical implementation, how would that look like in Guix's guile-jwt package? What would the snippet actually do? Thanks, Aleix On Wed, Aug 17, 2022 at 12:23 PM Maxime Devos wrote: > > On 17-08-2022 18:22, Aleix Conchillo Flaqué wrote: > > Hi Maxime! > > On Tue, Aug 16, 2022 at 12:04 PM Maxime Devos > wrote: > >> >> On 16-08-2022 19:21, Aleix Conchillo Flaqué wrote: >> >> >> >> On Tue, Aug 16, 2022 at 9:59 AM Maxime Devos >> 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. > > Sometimes the source code of a package contains a copy of a dependency. > This is called 'bundling'. 'Unbundling' is the act of undoing the > 'bundling', this is often done by cleaning up the source code (with what we > call a 'snippet' in Guix: (snippet #~(delete-file-recursively > "googletest"))) and setting some configuration flags > ("-DUSE_SYSTEM_GOOGLETEST=yes" or such). > > For example, in Guix we occasionally encounter a bundled "googletest" (a > test framework). > > In this case, we are kind of (un)bundling the base64 module, though it's > not _exactly_ (un)bundling because, AFAIK, there is canonical upstream > location for the base64 module to replace things with. Still seems pretty > close to me. > > Upsides of unbundling, as mentioned in '(guix)Submitting Patches': > > Sometimes, packages include copies of the source code of their > dependencies as a convenience for users. However, as a > distribution, we want to make sure that such packages end up using > the copy we already have in the distribution, if there is one. > This improves resource usage (the dependency is built and stored > only once), and allows the distribution to make transverse changes > such as applying security updates for a given software package in a > single place and have them affect the whole system—something that > bundled copies prevent. > > Another benefit: reviewing for absence of malware is less work when > there's only a single copy to review, though I suppose that in this case > the module is so small the reviewing benefit is minimal. > > 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? > > It's an implementation detail of Guix, it's a file (from the new version, > not the old) that is loaded by "guix pull" in the old Guix to compile the > new version of Guix. > > 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)? > > Oops, that should have been guile-gcrypt -- it's a Guile package -- "guix > show guile-gcrypt" / > . > > Greetings, > Maxime. >