On Aug 12, 2009, at 7:56 PM, Andreas Rottmann wrote:
...
In the long(er) run, I think the R6RS community should work on an
installation system for library collections (like Perl's CPAN,
Haskells
Cabal, etc.). The current situation, where every other R6RS Schemer
has
her own library collection, copying code from each other, is quite
undesirable, IMO.
It is, indeed. The situation needs fixing, immediately.
...
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.
I agree. At the package/collection level, not at the library level.
- Parallel-installability of the same collection with different
versions, to ease transitions. A single program would just be
able to
use a single version of any library collection, but different
programs
could use another version of that same library
collection. Effectively, you'd have different views upon the set of
installed collections.
This might be hard if the different conflicting versions are installed
in the same "root", but should be easy if you allow different library
roots for different programs. This would replicate some library files
but may be the easy way out.
I think this idea may reasonably also be carried further, by
including
a user id in the collection's "version" component, to allow private
branches, as well as entirely avoiding the need for a central naming
"authority": If two people chose conflicting (R6RS) library names,
they'd be free to, but would force users to chose -- eventually
pressure from the userbase would rise, and the name conflict will be
resolved (or so I'd imagine ;-).
If two collections provide the same file, the collection manager or
whatever you wanna call it can mark them "conflicting", and the user
has to decide. Sure.
- 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.
Yes.
Question: can we use the debian tools (dpkg, apt-get, etc.) as is to
accomplish the task? What are the advantages/disadvantages? If not,
we can at least copy the state-of-the-art in dependency management,
conflict resolution, etc., instead of reinventing it.
- Provide a programmatic (i.e. Scheme) as well as a command-line
interface.
Yes. That would be nice so that libraries can query the system for,
say, package location in the file system, autoload enhancements if
they're available, etc.
I think there should be a single software package, using a liberal
(e.g. BSD) license that implements that library collection management
for R6RS implementations. Implementations could then include this
piece
of software, if they wish.
I'd appreciate feedback on this issue, and I'd be willing to join
hacking on a solution that targets R6RS implementations.
I think we can start with a simple solution and get it running
quickly if we avoid overengineering. Here's one simple idea and
some additional criteria to get things started. Feel free to shoot
it down.
1. A package should be *easy to create* so that people feel encouraged
to make packages without hassle.
2. Package format should be *easy to process* so that (a) we don't
spend too much time developing it, and (b) others can easily hack it.
3. It should *meet current needs* but not more.
One possibility is to make a package a simple zip file to begin with.
The zip file contains files and directories of course.
* We can consider top-level files "meta information", these may include
README, LICENSE, MANIFEST, COPYING, HACKING, or whatever. These
files
get copied into a <root>/meta/<package-name> directory. The MANIFEST
file would probably contain the author name, license info,
dependencies
on other packages, and small/long description.
* We consider top-level directories "information", and these include
library files (structured as directories), and may include other info
that these libraries need (text files, images, etc.). Typically,
there would be one directory per package, but there might be more.
These get copied into the <root> directory.
* The <root> directory can be either system-wide or user-specific.
I think we can start with having a single root and take it from
there.
The <root> directory can be added to IKARUS_LIBRARY_PATH, or whatever
and all libraries under the <root> would then just work.
* The package manager itself can be a package installed in its own root.
To bootstrap the system, you just unzip the package manager somewhere
and add its directory to your PATH.
* We let everything else work by convention and anarchy.
To serve packages (over HTTP), a repository is just a directory
containing
the packages' zip files and a special Packages files (like debian). The
Packages file contains the information that the tools need: list of the
package names, authors, dates, files and directories, dependencies, etc.
The package manager has a list of repositories and you can do apt-get-
style
management.
For people who host their libraries on bzr/git, we can probably make a
quick repositories that periodically pulls changes, builds zip files,
and updates the Packages files. So, we can have a semi-centralized
place where one can obtain all interesting packages.
I don't think this would take more than a week of hacking, if we use
existing tools (e.g., curls for HTTP, zip for packing/unpacking, etc).
How does this all sound? Criticisms most welcome.
Aziz,,,
