There have been a lot of good ideas presented on this topic, and I
agree with most of them. I'd like to lay out a few ideas, some of
which restate things that have already been said, but which I hope can
help to flesh out a vision of what we're trying to accomplish.
1. Installing a library (and its dependencies) should be as `no-brain'
as possible, even if that limits the power of the library manager.
Ideally it should be something like
schemelib --install munglib --atleast 8.02
to install version 8.02 or better of munglib, along with its
dependencies (and this should be in a GUI version as well).
I'm not saying that there should be a way to trick the library manager
into doing the obvious thing, just that it should happen automatically.
Similarly, local library directories should be managed in an
appropriate way, considering that many Schemers would want personal
libraries, rather than system-wide ones. Ideally, the library manager
should allow users to forget about manipulating environment variables
completely.
A user should have to read not more than one screenful of text to get
far enough to set up a local library directory (that works with Ikarus
and/or other Schemes) and start installing libraries. (The library
manager might well require a 100-page manual for full use; I just want
this use case to be simple and straightforward.)
2. The library manager should be bundled with the Scheme system, so
that users don't have to do anything to get it going. The bundle
should include programs such as wget, curl, bazaar, and/or git,
whatever is needed to make everything work.
3. While I am not a great fan of Microsoft, getting things running on
Windows is always a good thing; I even think native Windows Ikarus
would be a good thing :-). To this end, there's no reason why one
should use Unix-specific things when a more generic approach is almost
as good. For example, zip doesn't compress as much as gzip or bzip2,
but it's almost as good. Similarly, symbolic links don't work on
Windows, so we can live without them.
4. Versioning seems to be a horrible issue everywhere I've worked. The
main problem is that if you get too specific, then you are basically
defining a software process, but if you get too vague, then the
numbers become meaningless. I would suggest a somewhat simple
versioning scheme that people can understand and apply, rather that
(a) a very complex system, or (b) something that defines only the
syntax but not the semantics of version numbers.
5. Documentation is not optional. Some relatively simple documentation
strategy ought to be part of the package definition, so that a user
can do
schemelib --viewdoc munglib
to see the documentation on this library. HTML is a fine standard for
documentation here.
6. The packaging job should be simple rather than complex. I would go
for a format where the top level of a package contains the metadata
and documentation, and then there's a directory containing the actual
library files. Thus for munglib, the top level has README, COPYING,
MANIFEST, and DOCUMENTATION.html, and then there's a munglib directory
that contains the actual Scheme code.
7. Having multiple back ends sounds nice in principle (and the
Launchpad versus GitHub arguments can be a lot of fun :-), but think
of the version skew when a library maintainer decides to move the
authoritative version of something from one repository to another.
Things like CPAN and CTAN work because everything is mirrored. Failing
that, I can easily see users becoming hopelessly confused about where
to get a specific package. I would prefer to keep that part as simple
as possible.
I'd ideally like to see a library manager that works essentially
unchanged (though there might be system-specific code) on as many R6RS
systems as possible.
Where do we go from here?
-- v
