alternative mechanisms for including config

[Adam Spiers]

On Mon, Dec 5, 2011 at 12:57 AM, Adam Spiers <vcs-home at adamspiers.org> wrote:
> On Sun, Dec 4, 2011 at 9:11 PM, Joey Hess <joey at kitenet.net> wrote:
>>        If a machine-parseable list of repositories is needed,
>>        I think it'd be better to have a perl function that emits
>>        it in one go.
>
> I don't see how that's possible without ignoring the `skip',
> `deleted', and `include' parameters.

This may be a good time to discuss the design of the `include'
parameter.  When you were deciding what its value should be, I guess
there were at least three possibilities:

    (1) a chunk of shell-code which returns the actual shell-code to
        include

    (2) a chunk of shell-code which returns a list of names of files
        to include

    (3) a delimited list of files to include

You went with (1).  One advantage of this is the ability to
dynamically generate code to include.  But this could also be achieved
with (2), by generating the files to include and then returning the
names of the generated files.  Also, with (1), if the shell-code has
an issue it's harder to debug because there's no containing file (and
line number and surrounding lines) to refer to.  The main advantage of
(3) is that you don't have to execute any shell code at all.  This
would facilitate implementation of your suggestion of writing a Perl
function to emit the repo list, although there's still the problem of
the `skip' parameter, and I suspect too many users are already relying
on the dynamic nature of `include' for (3) to be feasible.

But might it be worth implementing (2) alongside the existing (1), via
a new `includefiles' special parameter?