Am Mi., 26. Okt. 2022 um 18:11 Uhr schrieb Marc Feeley - feeley at
iro.umontreal.ca (via srfi-discuss list)
<xxxxxx@srfi.schemers.org>:
>
>
> > 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

Maybe we should have the mapping the other way around (under the
assumption that (possibly temporary) locations should not be part of
the official library name):

The library name is just (srfi 233). Now, if a program has an import
clause like (import (gitlab.com/gambit/srfis srfi 233)), the
implementation checks whether the url belongs to a list of trusted
ones, creates an alias from (srfi 233) to (gitlab.com/gambit/srfis
srfi 233) on the fly, downloads the library implementation and finally
loads it.

This does not provide a solution to decentralized namespaces, but it
retains the feature of easy installation.

The namespace problem has to be solved differently; this may not be a
problem in practice. the Scheme library namespace is much larger than
the, say, C library namespace.