[PATCH 2 of 5] extdata: add revset support for extdata

[Yuya Nishihara]

On Sat, 24 Sep 2016 00:22:47 +0200, Pierre-Yves David wrote:
> On 09/23/2016 07:34 PM, Matt Mackall wrote:
> > On Fri, 2016-09-23 at 19:49 +0900, FUJIWARA Katsunori wrote:
> >> At Thu, 22 Sep 2016 13:21:36 -0500,
> >> Matt Mackall wrote:
> >>> # HG changeset patch
> >>> # User Matt Mackall <mpm at selenic.com>
> >>> # Date 1474293900 18000
> >>> #      Mon Sep 19 09:05:00 2016 -0500
> >>> # Node ID 9c8847df32a0c5045e60aded2e03a9c97507f909
> >>> # Parent  19bf2776dfe39befdc479253e1e7d030b41c08f9
> >>> extdata: add revset support for extdata
> >>>
> >>> This inserts extdata into the revset function support. Planned
> >>> extensions of extdata support arguments, so this is the most
> >>> appropriate place for it.
> >>>
> >>> Unfortunately, the registrar framework is not a good fit here. First,
> >>> setting an appropriate load point is still an unsolved problem (we
> >>> want the code to live in revset.py, but that module may never be loaded).
> >>> Second, registered methods become global and the data sources are likely to
> >>> be
> >>> repo-specific. This won't work well in a context like hgwebdir.
> >> Is there any reason not to define extdata() revset predicate (or
> >> template function), which requires external data source name like as
> >> extdata('filedata') ? (for convenience ?)
> >
> > It's mostly convenience. But I also plan to add support for arguments.
> 
> I think I really like foozy idea about using a generic 'extdata("key")' 
> predicate. That will probably be okay for many case and prevent 
> unexpected collision with other revsets. If needed, the user can easily 
> define a revset alias for the sources in needs easy access to. As 
> configuration of the source is needed anyway, this does seems like a 
> bearable burden.
> 
> If I remember correctly, it does not seems to have limitation in the 
> current implementation of revset that would prevent use to do 
> 'extdata("key", arg1, arg2)'

+1 for 'extdata(key, ...)', which I think will make things simpler. We'll
need to mark it as a slow function in optimize().

If we want a key(...) alias by default, we could rewrite the parsed tree.