On Thu, Aug 18, 2022 at 12:56 AM Maxime Devos <maximedevos@telenet.be>
wrote:

> 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.
>
> It's not some Guix-specific quirk. It's the same for at least Debian. It
> benefits not only Guix itself but all users of the software:
>
Thanks, I understand the benefit now.

> [...] allows [...] 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.
>
> ... that was written with Guix in mind, but it applies to every
> distribution and everyone.
>
> Besides, your goal appears to be to unbundle the base64 into a single
> location (as a module of Guile), if we do that I think we should go all the
> way -- just adding it to Guile increases bundling instead of decreasing
> bundling, only if the various upstreams are modified to unbundle and use
> the new location then the unbundling is completed.
>
I see... In my mind, initially, I was thinking the opposite. By adding it
to Guile, new projects will use the new base64 module and existing projects
will update whenever they want.

On 18-08-2022 02:09, Aleix Conchillo Flaqué wrote:
>
> About Guix's unbundling (maybe that's something that should go on Guix's
> mailing list),
>
> I don't see why, there's nothing to write about except "oops some packages
> are bundling base64, let's unbundle those", and for unbundling those, it
> seems more practical to write about that here on guile-devel. Also I
> noticed I sent some messages to guix-devel instead of guile-devel,
> correcting now.
>
> 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?
>
> Currently, it's not done yet, presumably for that reason and maybe also
> due to nobody having noticed it yet?
>
> How it would look like, for upstreams that refuse to unbundle or are
> unresponsive:
>
> #~(begin
>         (delete-file "local/copy/of/base64.scm")
>         [also remove it from the Makefile.am]
>         (substitute* (find-files "." "\\.scm$")
>           (("(\\local base64 module\\)") "(gcrypt base64)")))
>
OK, I was imagining something like that. In this case do we assume (gcrypt
base64) is installed? Because some projects don't have a dependency on
guile-gcrypt.

> For responsive upstreams that do not mind these kind of improvements,
> there is a preference for submitting a patch upstream -- that way, everyone
> benefits, not only Guix.
>
So, what do you think would be the way to proceed in order to include a
base64 implementation in Guile itself?

For example:

1. Add (ice-9 base64) (or (encoding base64)) to Guile and let new projects
and existing projects to update with conditional module loading to support
old versions of Guile.
2. Do unbundling in Guix packages both for projects that have not updated
upstream and for projects in (1). The unbundling would be done by pointing
to Guix's (or guile-gcrypt) base64 implementation, or is there a way they
could point to Guile's implementation?

Does that make sense or am I still missing something (I'm about to catch a
cold so my brain is not working quite well this week)? Originally, I was
thinking only in (1).

Thanks!

Aleix