> On Apr 25, 2021, at 11:22 AM, Lassi Kortela <xxxxxx@lassi.io> wrote:
>
>
> So (github.com/account/repo foo qux) is just a library name. _Unless_ we have added a rewrite rule that says to translate any library name part with slashes into a git repo URL. So this:
>
> (import (from-package "git://xxxxxx@github.com:accout/repo.git" (foo qux))
>
> Could be derived from (github.com/account/repo foo qux) using a rewrite rule, something like this:
>
> (rewrite-import
> (github.com/<acctname>/<reponame> <libname> ...)
> (from-package
>  (string-append "git://xxxxxx@github.com:" <acctname> "/" <reponame> ".git")
>  <libname> ...))

Library name rewriting is a useful feature.  However I think your example is backwards.  What is needed is a rewrite of (foo qux) to (github.com/account/repo foo qux).  It is important however that the place where this rewrite rule is expressed is as close as possible to where the library is referred to in the source code.  For example it could be a “config” or “alias” file that is in the same directory, or a parent directory (up to the root of the package).  A global alias file (that is part of the Scheme installation) is also a possibility but it should be a last resort as it is much more brittle (two users may get wildly different experiences if they have different global alias files).  What I’m advocating is a kind of lexical scoping of alias rules, where the directory nesting models the lexical nesting.

Marc