Email list hosting service & mailing list manager

Libraries at scheme.org? Lassi Kortela (26 Jan 2021 22:49 UTC)
Re: Libraries at scheme.org? Vladimir Nikishkin (27 Jan 2021 01:28 UTC)
Re: Libraries at scheme.org? Lassi Kortela (27 Jan 2021 07:27 UTC)
Re: Libraries at scheme.org? Vladimir Nikishkin (27 Jan 2021 01:34 UTC)
Re: Libraries at scheme.org? Lassi Kortela (27 Jan 2021 07:46 UTC)
Re: Libraries at scheme.org? Arvydas Silanskas (27 Jan 2021 08:25 UTC)
Re: Libraries at scheme.org? Marc Nieper-Wi├čkirchen (27 Jan 2021 08:36 UTC)
Re: Libraries at scheme.org? Lassi Kortela (27 Jan 2021 08:51 UTC)
Re: Libraries at scheme.org? Arvydas Silanskas (27 Jan 2021 10:34 UTC)
Re: Libraries at scheme.org? Marc Feeley (27 Jan 2021 13:17 UTC)
Re: Libraries at scheme.org? Lassi Kortela (27 Jan 2021 14:07 UTC)
Re: Libraries at scheme.org? Marc Feeley (27 Jan 2021 16:28 UTC)
Re: Libraries at scheme.org? Lassi Kortela (27 Jan 2021 17:34 UTC)
Re: Libraries at scheme.org? Lassi Kortela (27 Jan 2021 18:09 UTC)
Re: Libraries at scheme.org? Marc Feeley (27 Jan 2021 19:54 UTC)
Re: Libraries at scheme.org? Lassi Kortela (29 Jan 2021 13:28 UTC)
Re: Libraries at scheme.org? Lassi Kortela (27 Jan 2021 08:37 UTC)
Re: Libraries at scheme.org? Duy Nguyen (28 Jan 2021 10:29 UTC)

Re: Libraries at scheme.org? Lassi Kortela 27 Jan 2021 18:09 UTC

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