Re: Release time!

[Andreas Rottmann]

Ian Price <address@hidden> writes:

> address@hidden (Ludovic Courtès) writes:
>
>>> * Figure out a way to make Guildhall modules that will be overridden by
>>>   a matching module in core guile (if it exists).  This is important for
>>>   SRFIs.  Ian Price's Guildhall repository contains portable
>>>   implementions of several SRFIs that might become part of core Guile in
>>>   the future, and the core versions should take priority.
>>
>> Could guildhall use SRFI-0 to check whether a given SRFI is already
>> provided by the host’s Guile, and determine based on that whether to
>> install its own version?
>
> Well, maybe I could hack something that uses srfi-0, but it sounds kinda
> ugly, and liable to break if a guile upgrade changed the features it exported.
>
> Right now, a package can declare multiple 'provides' so that you can
> e.g. require srfi-1 and it would pull in the appropriate package. But as
> it stands, the provides are somewhat orthogonal to how the code gets
> installed.
>
> Andreas,
> Guildhall is a friendly fork of Dorodango, so what do you think about
> adding this sort of thing?
>
I've thought about this issue some time ago, but have not yet come to a
definite conclusion on how to handle this.  A rough idea is to add a
"proxy package" for the Scheme implementation of the destination
(i.e. installation target) to the `dorodango-support' bundle, which is
created upon initialization of the destination.

If that proxy package would "provide" (e.g. based on a feature check)
all SRFIs that are present in the target Scheme (aka "Guile" from now
on), that would bring us closer to the goal. If all SRFIs required by
the set of packages installed are indeed provided by Guile, no
additional package would be pulled in.  However, if a single package
provides multiple SRFIs, of which only some are provided by Guile, that
package will get installed to satisfy any requirements not met by the
proxy package, and will thus *override* any core SRFI implementation in
Guile that it provides as well.

However, there's a reasonable (I think) workaround: no longer `provide'
the SRFIs, but instead really use individual packages for them, so they
can be installed on an individual basis.  This is not as tedious as it
might sound: the pkg-list.scm file would have to list each SRFI, but the
collection of portable SRFIs can still be maintained in a single source
repository and dorodango bundle (i.e. unit of distribution).

Regards, Rotty
-- 
Andreas Rottmann -- <http://rotty.yi.org/>