Eduardo Cavazos wrote:
I have updated agave such that all the libraries and demo scripts now
are under the '(agave ...)' namespace.
From the README, the install instructions are now simply:
$ cd /usr/local/lib/ikarus
$ bzr branch lp:~ikarus-libraries-team/ikarus-libraries/srfi
$ git clone git://github.com/dharmatech/agave.git
And running a demo is still simply:
$ ikarus --r6rs-script /usr/local/lib/ikarus/agave/demos/flexi-line.scm
Here's one idea for an R6RS library installer.
I use github. Other folks use launchpad. Surely others will be used such
as Mercurial. Maybe somebody wants to serve up a library via http. A
library installer can abstract over all of those. The installer should
contact a library registry with some informational metadata, most
importantly the source location (git, launchpad, http, whatever
address). Optionally, if a specific version is requested, that version
should map onto a "tagged" branch of the version control system.
Anyways, once the installer locates the source, it does the right thing
to talk to the backend (git clone, bzr ..., etc).
That's it.
I don't care if you don't like it. :-) I'm just putting another idea out
there.
Here's a sketch of what I'm thinking:
http://github.com/dharmatech/epcot/tree/master
I.e.:
$ ikarus --r6rs-script epcot/install.sps agave
Will "do the right thing". Yeah, that should probably look like:
$ epcot agave
Each package has it's own metadata file in the "registry" directory. The
data is a simple list.
Need to update the registry? Submit a patch. ;-) Need to refresh your
local registry? Probably have a command like:
$ epcot --update-registry
Which basically does a 'git pull' behind the scenes.
Yes, I picked github and the storage but I'd be fine with launchpad or
whatever (although github seems to be much more lightweight and apropos
for something like this).
Ed
