[PATCH] config: add extension point for extracting all included files

[Yuya Nishihara]

On Wed, 1 Mar 2017 15:51:44 +0100, Mathias De Maré wrote:
> On 11-02-17 10:52, Yuya Nishihara wrote:
> > On Tue, 7 Feb 2017 15:31:02 +0000, De Mare, Mathias (Nokia - BE) wrote:
> >>>> On Feb 3, 2017, at 09:56, Mathias De Maré <mathias.demare at gmail.com>
> >>> wrote:
> >>>> # HG changeset patch
> >>>> # User Mathias De Mare <mathias.de_mare at nokia.com> # Date
> >>> 1486132049
> >>>> -3600
> >>>> #      Fri Feb 03 15:27:29 2017 +0100
> >>>> # Node ID ea2e95febfeff39377c878fa05cc853832bc3b2a
> >>>> # Parent  eb78ec9e97b70310e2944f72c29463bedfc21442
> >>>> config: add extension point for extracting all included files
> >>> Hmm... for those of us who haven't been paying close attention, can you say
> >>> more about why this is desirable? Generally we don't add an extension point
> >>> unless at least an in-tree extension uses it. (It's possible there are historical
> >>> exceptions to this.)
> >> Pierre-Yves and myself spent some time working on an extension that would allow users to share their configuration with a server and allow a server to send configuration suggestions to a client. The work so far is available at https://bitbucket.org/Mathiasdm/hg-configexpress/overview
> >> One of the possible suggestions to clients would be to add specific includes, and this extension point allows checking if these includes are present.
> > Can it be done by using/extending config._source dict?
> >
> > I don't think hooking config method is a good idea because config object
> > may be used to parse template maps, .hgsub, etc.
> config._source can't be used as it is (as it stores the absolute paths, 
> while config includes could be include with a relative path).
> 
> I guess one possible alternative would be to create a config._relsource 
> containing the relative paths, but that would require signature changes 
> to some of the config methods.
> Another option would be for hg-configexpress to implement parsing of 
> configfiles itself (only the 'includes' part), but that seems a bit 
> redundant.
> Finally, it would be possible to add 2 additional keyword arguments to 
> the 'include' function that's called inside config.config.parse, so it 
> would be something like: include(inc, remap=remap, sections=sections, 
> base=base, expanded=expanded)

Internal API changes should be okay. I don't know which would be better,
but both config._relsource and include() sound good to me.