[PATCH 2 of 2 RFC] config: introduce platform specific sections

[Gregory Szorc]

On Thu, Mar 26, 2015 at 7:35 AM, Yuya Nishihara <yuya at tcha.org> wrote:

> On Wed, 25 Mar 2015 21:15:27 -0400, Matt Harbison wrote:
> > On Mon, 23 Mar 2015 16:02:16 -0400, Matt Mackall <mpm at selenic.com>
> wrote:
> > > On Fri, 2015-03-20 at 18:36 -0400, Matt Harbison wrote:
> > >> # HG changeset patch
> > >> # User Matt Harbison <matt_harbison at yahoo.com>
> > >> # Date 1426888879 14400
> > >> #      Fri Mar 20 18:01:19 2015 -0400
> > >> # Node ID 636f51ff2cfc9bbd665f1b3bf198d780a2afffe8
> > >> # Parent  6b3aff8a06f1cf7057a9bdcdc5e301dde0801828
> > >> config: introduce platform specific sections
> > >
> > > Please take a peek at Greg's patches where he's proposing using
> > > [foo.bar] for something else. I can't say I'm excited by either
> > > proposal.
> > >
> >
> > Yep, I saw he hadn't ruled that out yet and pinged him on Monday.
> >
> > In the meantime, do you have any alternate ideas for this?  I wasn't sure
> > how your
> >
> >    new.style =
> >    old.style.path =
> >
> > suggestion would apply to this, since that probably requires knowledge of
> > what is possible in each section.  ([extensions] for example allows a
> > leading 'hgext.', so it isn't a general split on '.' and compare
> > algorithm.)
>
> As the magic is done at config.parse() layer, how about %if like a C
> preprocessor?
>
>   [systest]
>   %if $platform == 'win32'  # or %ifeq(...,...) ?
>   key = windowsvalue
>   %elif $platform == 'linux'
>   key = linuxvalue
>   %endif
>
> (I don't know if mpm likes it. ;)
>
>
I'm also not a huge fan of adopting [X.platform] for platform-specific
bits. That prevents us from using [X.Y] sections for anything else, which I
think is a bit short-sighted.

I kinda like the preprocessor idea. Although, the more I interact with
preprocessors, the more I learn that it is often best to avoid them. Once
you introduce a preprocessing step, any tool that parses the file needs to
know about preprocessing. And since Mercurial doesn't have a built-in
config editor, this would further limit the ability for 3rd party tools to
rewrite Mercurial's mostly-ini config files. (The "mercurial-setup" tool I
wrote for Mozilla is one such tool.)

I'm a much bigger fan of sticking to defined data formats as much as
possible. i.e. "use ini."

Here are some alternatives.

Introduce special options within sections to denote properties. e.g. all
UPPERCASE options could be reserved for metadata:

[systest]
PLATFORM = win32
key = windowsvalue

[systest]
PLATFORM = linux
key = linuxvalue

[systest]
PLATFORM = linux, osx
key = posixvalue

Or, put special syntax in the section title after a space.

[systest platform=win32]
key = windowsvalue

[systest platform=linux,osx]
key = posixvalue

Not as powerful as preprocessing, yes. But it preserves ini compatibility,
which I don't think should be under-estimated.

(FWIW, the %include directive supported in config files today already
breaks ini compatibility.)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://selenic.com/pipermail/mercurial-devel/attachments/20150328/11d96396/attachment.html>