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 Marc Feeley 26 Oct 2022 16:11 UTC

> On Oct 26, 2022, at 11:29 AM, Marc Nieper-Wißkirchen <xxxxxx@gmail.com> wrote:
>
> One reason why it is actually not a good idea to have library names
> like (github.com/gambit/examples hello) just occurred to me:
>
> If, at some point, an author decides to move their repositories from,
> say, GitHub to GitLab or Codeberg, or Savannah (which can be due to
> political reasons or because some repository provider ceases to
> exist), the names of this author's libraries would no longer reflect
> where they can be found.  While this would not harm the functionality
> of the libraries, it would confuse users (who like to click on the
> auto-formatted links in their editors) and loaders that pull source
> code directly from the internet.  Of course, the libraries could be
> renamed, but this should only become necessary if a new version of the
> library becomes gravely incompatible with the previous version.
>
> Making a library name dependent on a location thus clashes with its
> primary use of giving a (universal) name to a particular library.  In
> other words, it makes sense to base a library name on a URN, but not
> on a URI.
>
> A URN-like scheme (the SRFI process is one) at least solves the
> problem with namespacing.  What's missing is a connection between URN
> and URI, which should not be part of the library definition by the
> above reasoning.  It belongs to some metadata outside of the library;
> this necessary metadata can also contain some solutions for security
> issues.

With URNs we are back with the problem of a centralized system. Some organization has to assign names and “bless” the libraries as conforming to the standards it has. It also makes installing libraries a necessary step and harder when you want some library that isn’t blessed.

A situation that concerns me is the period of time when a library is being developed and not yet ready to be published on the centralized system.  I view libraries as organisms that evolve over time rather than pristine things that will never change (I view SRFIs as the latter, and not the “usual case” for a library). What if you want other developers to try out your “WIP library” and maybe collaborate with its development? You would need a separate installation process for this case, which is just an added barrier to collaboration.

The solution to the problem you mention is to allow a configurable mapping of library names. This is what the Gambit define-module-alias does:

(define module-alias (github.com/old-account/old-lib-name) (gitlab.com/new-account/new-lib-name))

So the URI in the library name is fundamentally just a way to identify the library unambiguously. In the great majority of cases the URI also points to the repository where the library source code can be found. [Fun fact: if you move a github repository to a new account and/or repository you can still access this new repository using the old name.]

Aliasing is also useful to give a meaning to certain library name prefixes, for example

(define-module-alias (mylib) (gitlab.com/new-account/new-lib-name x y z))

allows (import (mylib a b c)) that is equivalent to (import (gitlab.com/new-account/new-lib-name x y z a b c)) .

Library registries could simply be a file that gives a list of these mappings so that high-level names could be mapped to specific repositories. In fact, a “registry” could be a Scheme library that sets up all the mappings. Then it would be as simple as doing (import (scheme.org/libs)) to get those mappings.

Marc