summer of code project: cpan

summer of code project: cpan

[Andy Wingo]

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).

Locally it uses something like stowfs and $XDG_DATA_DIRS, as noted in
the previous SoC thread.

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.

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.  As far as flavor
goes, I want to tie it to the Guile project (and indeed: I want it to
tie the Guile project together), but I would also like for it to support
portable repositories, so that you could "guido install" R6RS libraries.

Regards,

Andy
-- 
http://wingolog.org/

Re: summer of code project: cpan

[Andreas Rottmann]

Andy Wingo <wingo@pobox.com> 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/>

Re: summer of code project: cpan

[Peter Brett]

Andy Wingo <wingo@pobox.com> writes:

> 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).
>
> Locally it uses something like stowfs and $XDG_DATA_DIRS, as noted in
> the previous SoC thread.
>
> 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.

I urge caution. This sounds suspiciously similar to Ruby "gems", which
have worked okay for developers but have caused massive problems for
system administrators, end users and distributions.

This article on LWN is a good read (although it contains some unrelated
criticism of other aspects of Ruby development).

http://lwn.net/Articles/423732/

Regards,

                             Peter

-- 
Peter Brett <peter@peter-b.co.uk>
Remote Sensing Research Group
Surrey Space Centre

Re: summer of code project: cpan

[Andy Wingo]

On Tue 29 Mar 2011 15:51, Peter Brett <peter@peter-b.co.uk> writes:

> Andy Wingo <wingo@pobox.com> writes:
>
>> Now that GNU is in the Google SoC, I'd like to propose again a CPAN for
>> Guile.
>
> I urge caution. This sounds suspiciously similar to Ruby "gems", which
> have worked okay for developers but have caused massive problems for
> system administrators, end users and distributions.
>
> This article on LWN is a good read (although it contains some unrelated
> criticism of other aspects of Ruby development).
>
> http://lwn.net/Articles/423732/

Valid points, all.  I think the thing to do is to make it easy to
package Guile modules, as stored and versioned in our CPAN, as native
packages.  People who want to use native packages can do that.  The
repository can have an idea of what's installed on the system, and
what's installed by the user.  Guile developers can easily publish and
distribute code via the CPAN, just as Perl developers do.

Andy
-- 
http://wingolog.org/