[PATCH] fancyopts: making config defaults actually override defaults

[Rodrigo Damazio]

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? :)

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?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.mercurial-scm.org/pipermail/mercurial-devel/attachments/20170322/d228eac6/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4847 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://www.mercurial-scm.org/pipermail/mercurial-devel/attachments/20170322/d228eac6/attachment.bin>