[PATCH] fancyopts: making config defaults actually override defaults

[Rodrigo Damazio]

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")

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.mercurial-scm.org/pipermail/mercurial-devel/attachments/20170314/1df5cece/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/20170314/1df5cece/attachment.bin>