alternative mechanisms for including config

[Joey Hess]

Adam Spiers wrote:
> 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?

I've made mr show the included line content in error messages now.
The speed hit of running that one shell command is minor.
It doesn't seem worth bothering users with deprecating the current
include, and needless complication to have a separate way with a list of
files.

-- 
see shy jo
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 828 bytes
Desc: Digital signature
URL: <http://lists.madduck.net/pipermail/vcs-home/attachments/20111205/9477f65c/attachment.pgp>