On Aug 15, 2009, at 3:06 AM, Vincent Manis wrote:
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
Yes.
(and this should be in a GUI version as well).
Future work.
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.
Yes. To start, we assume a single user-specific root.
Ideally, the library manager should allow users to forget about
manipulating environment variables completely.
After an initial install, yes. (you still need to set up where the
root is, and probably add it to your library path or whatever your
scheme implementation uses)
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.)
Yes.
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.
No. The library manager is a separate entity that's independent of
any Scheme implementation. You only need one library manager to
use. If each of Ikarus, Larceny, PLT, Ypsilon, IronScheme, Mosh,
etc. installs all the tools, it would be a mess.
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.
I agree that we should not rule out any platform by design. There
will be compatibility bugs that we have to sort out.
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.
I agree in principle. It is, however, a horrible issue that's
intrinsic to software itself. We should either go with something and
live with the consequences, or ignore versioning completely for now
and make it future work. Ignoring it for the time being may not be
the worst thing, since we have only a few libraries and all of them
are being actively developed. So, we can just say "give me the
latest xitomatl" and it should work for the time being.
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.
Future work.
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.
I think we're all in agreement on the broad lines here. It's all in
the details.
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.
The library manager should interact with repositories. Repositories
fetch, construct, and mirror packages from different sources. So,
the manager itself need not deal with this complexity.
Aziz,,,
