> On Jan 27, 2021, at 1:09 PM, Lassi Kortela <xxxxxx@lassi.io> wrote:
>
>> An unconventional approach would be for the Scheme library names to refer to a package index. The index would map library names to package (e.g. git repo or tar file) URLs. So the user would import libraries and the right packages would be consulted transparently.
>> From a security perspective, this requires the package index to be trusted in addition to the git repos from which packages are fetched. The index also needs to be updated frequently in order to present an up to date picture of all available libraries. This is all quite a bit more complicated than having the user type packages URLs directly into Scheme (import ...) clauses.
>
> In fact, this approach is identical to having the index as a package!
>
> 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.
>
> So your idea of having packages (as in, collections of RnRS libraries) be a part of the library name in (import ...) is probably best.
>

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.  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.  Perhaps that’s what you are saying and I am misunderstanding your message.

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))

Marc