> 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