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? Marc Feeley 27 Jan 2021 19:54 UTC

> 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