variables for plug-ins

[Adam Spiers]

Hi Dieter,

On Thu, Dec 1, 2011 at 8:12 AM, Dieter Plaetinck <dieter at plaetinck.be> wrote:
> On Thu, 1 Dec 2011 00:20:54 +0000
> Adam Spiers <vcs-home at adamspiers.org> wrote:
>
>>       [shell-config]
>>       checkout = git clone ...
>>       stowable = true
>
> Is this the right way to go? that mr plugins expose themselves by
> introducing a new variable just to enable them?  I think vcsh was
> planning to do the same.  Why not have a 'type' variable or
> something which can be set to stow/vcsh/...

Thanks for the reply.  Just to clarify, the plugin is first enabled by
the standard mechanism:

    include = cat $plugins_dir/stow

but this only has any noticeable effect on any repository when you add
the 'stowable = true' line to it.

However, it does not make sense to think of this as setting the 'type'
of the repository, because it's possible for a repository to utilise
multiple plug-ins at the same time.  For instance you could have a
repository which is stowable but is also retrieved via my 'download'
plugin.  So the only sensible definition of the repository 'type' is
whichever vcs_test returns true for it (and the stow plug-in does not
add a new vcs_test).

By the way, my patch to add support for ${action}_append makes it
easier for multiple plug-ins to cooperate:

    https://github.com/aspiers/kitenet-mr/commit/append

since they can all extend actions in different ways without
accidentally overriding each other's behaviour.

One other point: currently this stow plug-in works by treating
'stowable' as a new action.  That's not great because it requires a
sub-invocation of mr.  A more efficient way would be to write in the
mrconfig file:

    lib = mr_stowable=yes

and then have the stow plug-in do [ -n "$mr_stowable" ] tests.
However this is much uglier to read and write than "stowable = true".

Therefore what I would like to propose is a new special parameter
called something like 'variables', which lets you declare new
non-action parameters which would then be efficiently accessible by
any shell code that wants to use them.  This would offer an easy way
to configure DEFAULT and per-repo behaviour for any given plug-in.

Plucking an example out of thin air, here's how you might configure
stow to use hard links for a particular repository instead of the
default of symlinks.  The stow plugin would contain something like:

    [DEFAULT]
    variables_append =
        stowable
        stow_links_type

and the user's ~/.mrconfig would contain:

    [DEFAULT]
    stow_links_type = soft

    ...

    [repo]
    stowable = true
    stow_links_type = hard

Does that sound reasonable?