[PATCH] fancyopts: making config defaults actually override defaults

[Martin von Zweigbergk]

On Wed, Mar 22, 2017 at 10:14 AM, Rodrigo Damazio <rdamazio at google.com> wrote:
> On Wed, Mar 22, 2017 at 3:50 AM, Ryan McElroy <rm at fb.com> wrote:
>>
>> Rodrigo: for some reason, patchwork thinks you are Martin. Any idea why?
>> https://patchwork.mercurial-scm.org/patch/19133/
>
> No idea, but I'm using a script he created for mailing patches directly to
> gmail's backend servers (to avoid reformatting) - Martin, any chance you
> hardcoded your own address there? :)

Nope. IIUC, patchwork has decided to associate any email from
mercurial-devel at mercurial-scm.org with me, because it probably first
received one from there from me. And the reason it is from
mercurial-devel at mercurial-scm.org in the first place is because we
(Google) set the DMARC/SPF/whatever headers to prevent spoofing of
@google.com addresses, so the mailing list has no choice but to
rewrite it as coming from the mailing list itself. I may very well
have misunderstood how that works, but hopefully you get the idea
anyway.

>
>> On 3/14/17 10:16 PM, Rodrigo Damazio via Mercurial-devel wrote:
>>
>> On Tue, Mar 14, 2017 at 12:50 PM, David Soria Parra
>> <dsp at experimentalworks.net> wrote:
>>>
>>> On Sat, Mar 11, 2017 at 06:03:30PM -0800, Rodrigo Damazio Bovendorp via
>>> Mercurial-devel wrote:
>>> > # HG changeset patch
>>> > # User Rodrigo Damazio <rdamazio at google.com>
>>> > # Date 1489274373 28800
>>> > #      Sat Mar 11 15:19:33 2017 -0800
>>> > # Node ID 8c833b81a994e2d3304c3b06793f536355528aab
>>> > # Parent  62939e0148f170b67ca8c7374f36c413b67fd387
>>> > fancyopts: making config defaults actually override defaults
>>> >
>>>
>>> Overall this LGTM, and clearly makes defaults much better :).  My concern
>>> is that we are encouraging the use of defaults again, while they are
>>> deprecated. Defaults have inherent problems that they overwrite arguments
>>> which might be mutable exclusive with others (e.g. --graph in incoming
>>> and outgoing), or lead to undesired behavior if it's set by an admin. an
>>> exmaple
>>> is if you would specifiy defaults.update.check=True, the user will not
>>> find an
>>> --no-check option in the help message or anywhere else. This is not a
>>> problem if
>>> we assume defaults are alway set by the user and he knows about them.
>>
>>
>> Thanks for the review.
>>
>> Yes, we discussed the update --check case specifically during Sprint:
>> https://public.etherpad-mozilla.org/p/sprint-hg4.2
>> (search for "Flags and defaults breakout")
>>
>>
>> Note that I copied the notes over the the wiki for posterity:
>> https://www.mercurial-scm.org/wiki/4.2sprint/Notes
>>
>> If people do some cleanup passes and categorization, that would be useful.
>> I may contribute here at some point as well.
>>
>>
>> The conclusion was that this gains us the ability to do proper single-flag
>> overrides, which is good, but doesn't solve all the issues. There are other
>> changes we also want to make flags and defaults useful again:
>> - make the passed-in flag values not be simple primitive types, but rather
>> enhance them with addition information about where the value is coming from,
>> so commands like update can decide that an explicit --clean overrides a
>> system default of --check, and should only fail if both come from the same
>> level
>> - we want to add a --no- counterflag for every flag, not just booleans, as
>> a way to unset it (useful for revision-specifying flags for instance)
>> - we want to add environment variables to the stack of overrides along
>> with the different levels of config files and command-line arguments
>> - we want to try making all positional arguments map to flags (e.g. "hg
>> update 123" would be equivalent to "hg update -r 123" by making 123 be
>> passed to the command as the -r flag, also allowing config overrides for
>> those)
>> - we want to investigate why we support callables in flag defaults, and
>> remove support if that's not useful to anyone
>>
>>
>>
>> While I like this initial direction, I think this needs to be turned into
>> a series of smaller steps, and we need more discussion around whether we
>> will revive the defaults section or keep it deprecated. I'll drop this from
>> patchwork for now while we discuss.
>
>
> No problem. How/where/when/what would you like to discuss?
>