It is not so much a “package manager” that is needed but rather the
specification of a “package structure” that all of the libraries
would need to follow (e.g. a git repository would need such and such
a file and subdirectory in such and such a place of the main
directory). Then each Scheme implementation can extend their
current package manager to install these libraries.
+1
Of course a
generic package manager could be written for the Scheme
implementations that don’t have a builtin package manager.
https://akkuscm.org/ supports 13 implementations
Also the syntax for the library names would need to be reserved. I
have advocated a syntax that uses the URL as part of the name, e.g.
(github.com/feeley/digest) or
(github.com/feeley digest), so that the
package manager can operate without a central registry of libraries,
I would make a difference between package names and library names. In
general, we are not interested in finding single libraries but packages
(that include meta-information and know about dependencies). It is the
packages that need to be found automatically. So it makes sense to
"name" packages through a URI, but libraries can still be named, as
usual, e.g. `(srfi 999)` or `(scheme box)` or `(nieper bubblesort)`.
A package is conceptually equivalent to a git repository in that it's a
collection of libraries. Of course, a library collection could also be
stored in a subdirectory of a git repo, not necessarily in the root dir.
Nested collections would be an abstraction that covers any mixture of
version control repos and directory layouts.
The package for my bubblesort would be "named"
<gitlab.com/nieper/bubblesort <http://gitlab.com/nieper/bubblesort>>. It
would contain a manifest like
(package
(author "Marc Nieper-Wißkirchen")
(license GPL-v3)
..
(defines (nieper bubblesort))
(cond-expand
((gambit)
(requires "gitlab.com/r7rs/box <http://gitlab.com/r7rs/box>"))
...))
...)
As a package author, I know that the "gitlab.com/r7rs/box
<http://gitlab.com/r7rs/box>" package provides `(scheme box)`.
https://github.com/pre-srfi/scheme-metadata-files has preliminary work
on surveying existing formats like this and distilling a generic format.
If there's agreement that this kind of direction is useful (I do agree
that it is), we should figure out where to do the design and
implementation work.
