>> If the index says things like
>>
>>   (library foo) => (github.com/example/xxxxxx@1.2.3 foo)
>>   (library bar) => (github.com/example/xxxxxx@1.2.3 bar)
>>   (library baz) => (gitlab.com/example/xxxxxx@1.2.3 baz)
>>
>> Then the natural way to implement the package index is to have it download and cache those library files from the git repos, and serve the cached files to Scheme implementations that request libraries from it.
>>
>> The index could keep those cached files in a single git repo.
>>
>> ...and we have arrived at a situation that is conceptually the same as fetching RnRS libraries from git repos, as far as the Scheme implementation is concerned.

> I’m not sure I follow completely but it sounds about right, except the “index could keep those cached files in a single git repo”.  If you do that then you have a centralized system, so authors have to go throught this centralized system to publish their work.  This causes delays and is a “single point of failure, and also brings politics into the process.  I prefer giving all authors the freedom to update their packages/libraries when they need/want to.

Good points all!

> On the other hand, a centralized repository would be good to store the location (URL) of various “well known” packages, but not the actual source code of the packages.  In other words a registry of well known packages.

So it would be like an URL shortener (tinyurl.com, bit.ly) but for
Scheme packages.

> The mapping of these library names to locations is essentially what I had in mind in the configuration files:
>
>      (define-module-alias (library foo) (github.com/example/aaaa foo @1.2.3))

Right. I'm still in favor or a general library-name rewriting system for
Scheme. It would let people do things like add/remove a prefix/suffix of
library names matching a certain pattern, and specify how library names
map to filenames. The filename mapping could be extended so that URLs
can be used in addition to local filenames.

If we do that, then connecting library names to git repos can be done as
a special case of the rewriting and URL mapping.

I suggest the following arrangement:

- We use the word "library" to mean libraries in the R6RS/R7RS sense.

- We use the word "repository" to refer to a collection of libraries
stored in one place (directory / git repo / tar file / ...).

- A Scheme implementation's library search path is a list of
repositories (directories, and optionally also support for git repos,
tar files, ...).

I tried to think yesterday about the precise syntax to differentiate
repository names from library names, but it's quite a tricky problem so
didn't yet come up with anything I liked.

A good conceptual model for the library namespace is the Unix file
system, which has one root directory, and devices can be mounted as
arbitrary directories in the hierarchy.

Newer Unix-like systems go further, and introduce union mounts, so more
than one device can be mounted at the same directory (with a precedence
order to settle which device wins in case of duplicate filenames).

We could think of (union-)mounting repositories into the library
namespace. The Scheme implementation's search path would be
union-mounted at the root of the namespace. Rewrite rules could be used
to mount other repositories at other parts of it.