Deploying registrar configs in a BC safe way

[Durham Goode]

On 10/25/17 5:48 AM, Augie Fackler wrote:
>
>> On Oct 25, 2017, at 07:51, Yuya Nishihara <yuya at tcha.org> wrote:
>>
>> On Tue, 24 Oct 2017 18:49:50 -0700, Gregory Szorc wrote:
>>>> On Oct 24, 2017, at 10:25, Durham Goode <durham at fb.com> wrote:
>>>>
>>>> I've been trying to update our extensions to support the new registrar class, and one thing I've noticed is that it's not really possible to have code that works with old versions of mercurial and new versions of mercurial at the same time, without having devel warnings. I can easily stub out the registration logic if the registrar module doesn't exist, but I can't leave the default values on the actual config accessor lines, which old mercurial versions would need.
>>
>> I made all extension-specific configs "dynamic", and add explicit defaults
>> to ui.config*() calls instead.
>>
>> https://urldefense.proofpoint.com/v2/url?u=https-3A__bitbucket.org_yuja_hgext-2Dtextful_commits_1f284a246abb&d=DwIFAg&c=5VD0RTtNlTh3ycd41b3MUw&r=nuarHzhP1wi1T9iURRCj1A&m=lR7l4BfqDK6q7Iea-79Q-h1teNA3oQLKKh7QiqDoA4M&s=2ycQgVlPv5dGVFQUeMGUTS1h8KHBikUl11j9FoGk7m4&e=
>>
>>>> I tried to think of some way to fix this, like by leaving the defaults on the config access line, but ignoring it somehow, but that sounds funky. Thoughts on how to fix this?
>>>
>>> How about making registrar instances on extensions have different behavior from core? e.g.
>>>
>>> * No devel warnings for e.g. missing default values for a few releases
>>> * Arguments to control which devel warnings are issued
>>
>> Or,
>>
>> * No devel warnings for the "ui.config()" default matching the "configitem"
>>  default, which should be harmless
>
> That seems like a good transitional step, I like it. What do others think?
>

That would work for me. Adding the register's isn't the painful or risky 
part, updating the defaults and refactoring to support old mercurial is. 
So this would address that issue nicely.