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 <maximede...@telenet.be>
wrote:
>
> On 17-08-2022 18:22, Aleix Conchillo Flaqué wrote:
>
> 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.
>
> 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" / <https://notabug.org/cwebber/guile-gcrypt>
> <https://notabug.org/cwebber/guile-gcrypt>.
>
> Greetings,
> Maxime.
>
