Re: summer of code project: cpan

[Andreas Rottmann]

Andy Wingo <address@hidden> writes:

> Hello all,
>
> Now that GNU is in the Google SoC, I'd like to propose again a CPAN for
> Guile.  (It does needs a proper name, but that name doesn't have to
> correspond to the name of the command-line utility; see my other mail
> about "guido".)
>
> The proposal would be to start from dorodango, and to use stowfs
> locally.  We keep (largely) the dorodango network interfaces, but the
> implementation exists in a Guile-specific project, with a non-dorodango
> name (so as not to conflict with Andreas's more portable project).
>
Well, I believe Dorodango is quite modular, and large parts could be
re-used as-is.  Obviously, I'd like to avoid a "real" fork of the
codebase -- ideally code should be able to flow easily between Dorodango
and its Guile-specific cousin in both directions.  I am also open to
reconsider design decisions, should some of them not make sense for
Guile.

> Locally it uses something like stowfs and $XDG_DATA_DIRS, as noted in
> the previous SoC thread.
>
Support for the XDG Base Directory Specification would indeed be welcome
in Dorodango. Also, I am actually quite fond of how GNU Stow works;
adding support for that as an additional mode of operation would be nice
mini-project.

> The project can be developed outside of Guile initially, just
> integrating by defining "guido" commands.  If everything works it can be
> integrated within Guile itself.
>
One thing that speaks against directly reusing the dorodango codebase
(and later moving parts of it into Guile core) is that it comes with
some dependencies (from Dorodango's own package metadata):

  (srfi)          ; Not relevant on Guile, it provides the required
                    SRFIs in core
  (wak-foof-loop) ; Used all over the place
  (wak-fmt)       ; Ditto
  (wak-irregex)   ; Used in a few places; SRE syntax is exposed to the
                  ; user, however
  (wak-parscheme) ; Used in only one place (minor UI code)
  (spells)        ; That one's really prevasive: pathnames, filesystem,
                  ; logging, ...
  (industria)     ; Only used for handling ZIP, which is quite slow on
                  ; Guile anyway.
  (ocelotl)       ; Weight-balanced trees, HTTP client, URIs.

> Andreas, what do you think about this?  If you are happy with this I
> would be most pleased to have you as a co-mentor.
>
I'd certainly be willing to answer all kinds of questions on the
Dorodango codebase and give advice as good as I can, regardless of what
direction the project takes.

I have a few ideas that would help bringing the codebase of Dorodango
"closer to Guile":

- Work on an SRE frontend to Guile's regexp engine.  I believe there
  might be some code out there doing that already (Guile-SCSH?).

- Introduce a Stow-like mode of operation.  This should be possible
  without abandoning the current ZIP support, and would allow for:

  - Using non-random-access archive files (e.g. tar.xz).

  - Using external programs to (completely) unpack a bundle, eliminating
    the current performance issue introduced by Guile's relatively slow
    number-crunching.

  - Eliminate the (hard) dependency on Industria.

So what remains as (quite) hard dependencies would be: foof-loop, fmt,
and spells; the others should not be too hard to eliminate in some way
or the other.

WDYT?

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