various suggestions for mr

[Adam Spiers]

On Fri, Oct 28, 2011 at 6:08 PM, Joey Hess <joey at kitenet.net> wrote:
> Having two namespaces for the same thing does not strike me as
> necessarily a good idea.
>
> But if you wanted to do that with mr, you could
> maybe take advantage of a little-known thing it does with determining the
> absolute path:
>
> joey at gnu:~>mkdir namespace
> joey at gnu:~>cd namespace
> joey at gnu:~/namespace>ln -s ~/lib/sound
> joey at gnu:~/namespace>ln -s ~/src/git-annex
> joey at gnu:~/namespace>cd git-annex
> joey at gnu:~/namespace/git-annex>mr update
> mr update: /home/joey/src/git-annex

I already did this; in fact I *had* to, in order to support GNU stow,
which requires the stow package namespace to be the list of
directories under a single "stow directory".  If you look for
$STOW_PKG_PATH in the code I originally posted, you'll see:

    STOW_DIR=$HOME/.cfg
    ...
    MR_NAME="`basename $MR_REPO`"
    ...
    STOW_PKG_PATH="$STOW_DIR/$MR_NAME"

and then post_{checkout,update} call the install() function which
does:

    ensure_symlink_exists "$STOW_PKG_PATH" "${MR_REPO%/}"

However, the basename operation does not preserve the uniqueness
property which $MR_REPO had, and that's why I say that we need an
additional namespace.  I can easily hack one, e.g.:

    [$HOME/.my-repos/foo]
    lib = MR_NAME=my-foo

    [$HOME/.upstream-repos/foo]
    lib = MR_NAME=your-foo

but that's ugly, and requires execution of shell code which would make
it difficult to implement a reverse lookup from package name to repo
path.

> The only problem with this approach is that it only work when inside the
> symlinked directory, so mr update in ~/namespace won't update the
> directories symlinked to there.

Right.  I feel like there's probably some elegant tweak we could make
to mr which would solve all this cleanly without much effort, but I'm
still trying to figure out what it is :-)

Let's examine the status quo.  Currently mr has:

  - a namespace for repositories (let's call it "R") which is a subset
    of the filesystem namespace, and values are specified in mr config
    section headers,

  - a namespace for mr config files (let's call it "C") which is a
    different subset of the filesystem namespace from R, and

  - a 1:many mapping between C and R, i.e. each config file can
    contain one or more repos.

I don't think there's anything wrong with this design - in fact that
1:many mapping is a nice configuration-time grouping mechanism, but
it's not quite enough to cater for some use cases.

For instance, sometimes it's just not acceptable to update all repos
at once, e.g. if you know that something is broken in repo X but you
really need the updates from repos Y and Z.

However mr cannot currently perform actions on repos at a finer
granularity than how they are grouped in config files.  So if you
wanted to update your 'zsh' and 'emacs' repos, you could only do that
if they were in a config file containing no other repos.  In general,
unless you restrict yourself to one config file per repo, there is no
way to get mr to operate on an arbitrary subset of R.

Similarly, if the 1:many mapping between C and R is used to logically
group repositories together (e.g. "CLI", "X11" and so on), there is no
way to get mr to operate on an arbitrary collection of groups.

Another issue is that whilst "mr -c $config ls" extracts mappings from
C to R, there's no way to extract the reverse mapping from R to C,
i.e.  "what config file do I need to use in order to perform actions
on repo X?"

In summary, maybe the tweak I'm looking for is simply to decouple
configuration-time grouping of repos from run-time selection of which
repos to act on:

    [$HOME/.my-repos/emacs]
    name = emacs

    [$HOME/.my-repos/zsh]
    name = my-zsh

    [$HOME/.upstream-repos/zsh]
    name = upstream-zsh

which would allow:

    $ mr -r my-zsh,emacs

And then the reverse mapping from R to C could be extracted via:

    [DEFAULT]
    showconfig = echo "$MR_CONFIG"

(except at the moment, MR_CONFIG isn't changed via includes
which could cause a problem.)