Email list hosting service & mailing list manager

SRFI sample implementation repository layout Marc Feeley (15 Oct 2022 11:19 UTC)
Re: SRFI sample implementation repository layout John Cowan (15 Oct 2022 15:00 UTC)
Re: SRFI sample implementation repository layout Lassi Kortela (15 Oct 2022 15:59 UTC)
Re: SRFI sample implementation repository layout Lassi Kortela (15 Oct 2022 16:16 UTC)
Re: SRFI sample implementation repository layout Marc Nieper-Wißkirchen (15 Oct 2022 22:18 UTC)
Re: SRFI sample implementation repository layout Arthur A. Gleckler (16 Oct 2022 04:52 UTC)
Re: SRFI sample implementation repository layout Arthur A. Gleckler (16 Oct 2022 05:05 UTC)
Re: SRFI sample implementation repository layout Lassi Kortela (16 Oct 2022 08:57 UTC)
Re: SRFI sample implementation repository layout Marc Feeley (16 Oct 2022 12:08 UTC)
Re: SRFI sample implementation repository layout Arthur A. Gleckler (18 Oct 2022 21:23 UTC)
Re: SRFI sample implementation repository layout Marc Nieper-Wißkirchen (19 Oct 2022 14:53 UTC)
Re: SRFI sample implementation repository layout Marc Feeley (19 Oct 2022 15:33 UTC)
Re: SRFI sample implementation repository layout Arthur A. Gleckler (19 Oct 2022 18:21 UTC)
Re: SRFI sample implementation repository layout Göran Weinholt (19 Oct 2022 19:35 UTC)
Re: SRFI sample implementation repository layout Arthur A. Gleckler (19 Oct 2022 21:50 UTC)
Re: SRFI sample implementation repository layout Marc Feeley (19 Oct 2022 22:11 UTC)
Re: SRFI sample implementation repository layout Göran Weinholt (26 Oct 2022 08:44 UTC)
Re: SRFI sample implementation repository layout Marc Feeley (19 Oct 2022 21:12 UTC)
Re: SRFI sample implementation repository layout Arthur A. Gleckler (22 Oct 2022 22:59 UTC)
Re: SRFI sample implementation repository layout Lassi Kortela (19 Oct 2022 21:37 UTC)
Re: SRFI sample implementation repository layout Arthur A. Gleckler (22 Oct 2022 22:54 UTC)
Re: SRFI sample implementation repository layout Marc Nieper-Wißkirchen (23 Oct 2022 08:34 UTC)
Re: SRFI sample implementation repository layout Marc Feeley (23 Oct 2022 13:47 UTC)
Re: SRFI sample implementation repository layout Marc Nieper-Wißkirchen (23 Oct 2022 14:35 UTC)
Re: SRFI sample implementation repository layout Marc Feeley (25 Oct 2022 12:17 UTC)
Re: SRFI sample implementation repository layout Arthur A. Gleckler (25 Oct 2022 15:24 UTC)
Re: SRFI sample implementation repository layout Marc Feeley (25 Oct 2022 17:26 UTC)
Re: SRFI sample implementation repository layout Arthur A. Gleckler (25 Oct 2022 18:10 UTC)
Re: SRFI sample implementation repository layout Marc Feeley (25 Oct 2022 18:37 UTC)
Re: SRFI sample implementation repository layout Marc Nieper-Wißkirchen (25 Oct 2022 19:50 UTC)
Re: SRFI sample implementation repository layout Arthur A. Gleckler (25 Oct 2022 20:18 UTC)
Re: SRFI sample implementation repository layout Marc Nieper-Wißkirchen (25 Oct 2022 19:22 UTC)
Re: SRFI sample implementation repository layout Marc Feeley (25 Oct 2022 20:57 UTC)
Re: SRFI sample implementation repository layout Marc Nieper-Wißkirchen (26 Oct 2022 09:03 UTC)
Re: SRFI sample implementation repository layout Marc Nieper-Wißkirchen (26 Oct 2022 15:30 UTC)
Re: SRFI sample implementation repository layout Arthur A. Gleckler (26 Oct 2022 15:33 UTC)
Re: SRFI sample implementation repository layout Jakub T. Jankiewicz (26 Oct 2022 16:03 UTC)
Re: SRFI sample implementation repository layout Per Bothner (26 Oct 2022 16:18 UTC)
Re: SRFI sample implementation repository layout Lassi Kortela (26 Oct 2022 16:02 UTC)
Re: SRFI sample implementation repository layout Marc Feeley (26 Oct 2022 16:11 UTC)
Re: SRFI sample implementation repository layout Marc Nieper-Wißkirchen (26 Oct 2022 16:34 UTC)
Re: SRFI sample implementation repository layout Lassi Kortela (26 Oct 2022 16:59 UTC)
Re: SRFI sample implementation repository layout Lassi Kortela (26 Oct 2022 16:37 UTC)
Re: SRFI sample implementation repository layout Marc Nieper-Wißkirchen (29 Oct 2022 11:12 UTC)
Re: SRFI sample implementation repository layout Daphne Preston-Kendal (16 Oct 2022 07:10 UTC)
Re: SRFI sample implementation repository layout Lassi Kortela (16 Oct 2022 08:34 UTC)
Re: SRFI sample implementation repository layout John Cowan (24 Oct 2022 19:00 UTC)
Re: SRFI sample implementation repository layout Marc Nieper-Wißkirchen (24 Oct 2022 20:25 UTC)
Re: SRFI sample implementation repository layout Arthur A. Gleckler (24 Oct 2022 21:17 UTC)
Re: SRFI sample implementation repository layout Arthur A. Gleckler (24 Oct 2022 21:14 UTC)

Re: SRFI sample implementation repository layout Lassi Kortela 16 Oct 2022 08:34 UTC

> 1. SRFI should not become a dumping ground of (effectively) documentation for random libraries that end up with only one implementation each, but a repository of improvements to the core Scheme language. But the current situation also makes SRFIs the easiest apparent way to get libraries into multiple implementations. That needs to change, or we’ll increasingly end up with the situation of libraries which shouldn’t really be SRFIs becoming SRFIs just to get them more widely supported.

+1 but we don't yet have an effective answer to the problem.

> 2. To that end, we need a common package manager for multiple Scheme implementations. We have a number of attempts such as Snow and Akku, but Marc Feeley’s decentralized approach seems like the best one to me so far. (A decentralized approach such as this makes supply-chain attacks Somebody Else’s Problem, for example.) I’ve had the rough details of such an approach sketched out for a while, but it would be a big effort to write the whole thing and make it actually work on multiple implementations.

I suggest the following decomposition of the problem:

- A standard for a "package.scm" metadata file. You'd put such a file in
a package's git repo, and package managers (including things like
indexers, and Gambit's built in package manager) would consult this file
to figure out how to deal with the package.

- A standard for how a package index is distributed over the internet.

- A canonical package index at packages.scheme.org.

Under no circumstances should we bless a particular piece of software as
the package manager of choice (whether for portable code or otherwise),
as this has not worked historically and is unlikely to work in the
future. We should proceed via standardization.

Does this correspond to your ideas?

IMHO we have both decentralized packages and package indexes.