"Andreas Rottmann" wrote: > people can get a first glimpse of it more quickly. > > [0] http://rotty.yi.org/software/sbank/tutorial.html
I should shut up because I am already horribly behind in the schedule I had dreamed for Nausicaa 10 months ago, but I will try to become an alpha tester for this. ([1] is not synchronised with [2] regarding the bug/issue tracking selection; GitHub has an issue tracker. Or do you want to use another one?) [1] <http://live.gnome.org/sbank> [2] <http://rotty.yi.org/software/sbank/> > I think the R6RS community should work on an installation > system for library collections (like Perl's CPAN, Haskells > Cabal, etc.). I am commenting on this, I hope only with a single post, but I do not want to put anyone's effort down nor to start any flame. While I have not reached the point of having a "final opinion" on this, I am against it. (More below) > The current situation, where every other R6RS Schemer has > her own library collection, copying code from each other, > is quite undesirable, IMO. It is, but we are all in the first stage, exploring what it means to build a collection for R6RS; IMHO it will take until the end of 2010 to end the first stage. Then library collections will be either merged, abandoned or reach some sort of specialisation. > Off the top of my head, here's a (certainly incomplete) > feature list I'd expect from a system for managing library > collections: > > - Dependency and version management on the collection > level. > > - Parallel-installability of the same collection with > different versions, to ease transitions. [...] > > I think this idea may reasonably also be carried > further, by including a user id in the collection's > "version" component, [...] > > - Provide support for installation both per-user, and > system-wide. Ensure that fabricating Debian or RPM > packages from a library collection is easy and > automatable as far as possible. > The solution I would like to see for all of this is to just let users install a collection in a versioned directory. Recently I did a series of Firefox installations to bisect upon an introduced bug; I installed ~30 of them. It was boring, all right, but I just did it using pathnames like "/opt/firefox/3.1.2"; I had to learn nothing to do this, I read no documentation. When finished, I wiped them out using tools I already knew. IMHO what is needed is an application-specific library-finder library: For each application (stable distribution or development environment) I should be allowed to indicate a custom library, with standard API, to map library specifications to library pathnames or library collection top directory. The API should be down to: (library-require <required-library-spec> <requiring-library-spec>) with this it does not matter if a collection's name has a user-id in it, or it has all the library specs prefixed with "(nausicaa ---)" or whatever. This should be the work of a command line switch: $ ikarus --library-finder ... > - Provide a programmatic (i.e. Scheme) as well as a > command-line interface. > > I think these issues have been tackled to various degrees > by solutions for Python, Ruby, Haskell et. al. My experience with Python packages (disclaimer: it's been a while ago) is that they are hard to use, above the "why not" level; I am no Python programmer and having to learn some Python and yet another package management tool just to try out an application is too much, so I end up not trying it. I speak only for Linux, here. I have built some experience with the Slackware package management, and given a tarball using the "normal" configure+make+make install procedure I can embed it quickly in my small infrastructure of shell scripts, which allows me to create a Slackware package and use it with no problems. With Python packages I was not even able to install in a temporary directory, without diving in documentation I was not eager to read (I gave up). It took me some time to learn Slackware packages and become comfortable with them (and they are maybe the simplest), so why should I be forced not to use them? The system is mine! :-) > On the Scheme side, there's Descot[1] and SNow![2] > (generic), as well as scsh-install-lib[3], PLaneT[4] and > Chicken Eggs[5]. Common Lisp has ASDF[6]. When I started with Lisp I tried Common Lisp. Knowing almost nothing of the language, and with no experience of CL's REPL, I tried to install some package with ASDF. I failed, and it was really frustrating. Whenever I see someone starting a repository, my heart feels sadness. I have seen some efforts fail, simply because developers were not using them; the final result was a waste of resources, probably with little or no lateral reward for the maintainer in terms of new stuff learned and such. A *lot* of work is needed to maintain such an infrastructure. My little experience with Tcl, years ago, is that having a project template helps a lot. They maintained a Sample Extension package[1] showing how to structure the package sources to make them manageable with an Autoconf+Make infrastructure they provide. That infrastructure attempts to support (with success!) all the platforms where Tcl is available; a lot of work went into it. I worked for me, at least... [1] <http://wiki.tcl.tk/5464> -- Marco Maggi
