The quoting logic here was actually insufficient, and would have had
bogus b-prefixes on Python 3. shellquote seems more appropriate
anyway. Surprisingly, only two tests have output changes, and both of
them look reasonable to me (both are in blackbox logs).
Spotted by Yuya during review.
I think this makes the code much clearer. I had to think for a bit to
unpack the old-school `condition and if-true or if-false` dance, and
formatting argument lists here shouldn't be performance critical.
This new option control whether or not color will be used. It mirror the behavior
of '--color'. I usually avoid adding new option to '[ui]' as the section is
already filled with many option. However, I feel like 'color' is central enough
to deserves a spot in this '[ui]' section.
For now the option is not documented so it is still marked as experimental. Once
it get documented and official, we should be able to deprecate the color
extensions.
There is more cleanup to do before that documentation is written, but we need
this option early to made them. Having that option will allow for more cleanup
of the initialisation process and proper separation between color
configuration.
We now run the color initialisation as part of the standard dispatch. This is
opening the way for multiple cleanups since we now have access to the multiple 'ui'
object and we'll be able to see difference between global and local config. This
cleanup will arrive in later changesets.
As a side effect, the '--color' flag is now working without the extension.
Since we now properly initialize color for each ui idependently, we get a
warning message twice.
dispatch calls help like a ninja if you give it a truly unknown
command, and that might want to be paged. If it gets paged, then the
'hg: unknown command' text gets eaten by a grue, unless we call the
pager first. This change rearranges the codepaths so we can safely
only invoke the pager in the case where we'll have long output from
the help command code, rather than just a short message like "did you
mean stat instead of start" or "fetch is provided by the fetch
extension".
I'm about to add direct paging support to some commands, and as a
result we need a way to communicate from the higher layers of dispatch
that paging is explicitly disabled.
This moves the global flag and the --pager=yes logic into core. Only
functionality change is that users now always get a --pager flag and
can enable the pager via the flag without the extension active.
Moving the flag into core exposes a defect in the ro localization,
which will have to be corrected later.
We want to log the time Mercurial spends trapped in things outside
programmatic control. Provide a mechanism to give us both command runtime
and as many different sources of blocking as we deem useful.
This makes it possible to profile extension loading and setup, which
takes a substantial fraction of overall execution time for fast
commands.
(99% of this commit is simply changes of indentation to reflect the
hoisting of the two calls to maybeprofile to a single one that
happens earlier.)
# no-check-commit
shlex.split() only accepts unicodes on Python 3. After this patch we will be
using pycompat.shlexsplit(). This patch also replaces existing occurences of
shlex.split with pycompat.shlexsplit.
Now that we have the '_style' dictionary in core, we can use the clean and
standard 'extraloader' mechanism to load extension's 'colortable'.
color.loadcolortable
keys of keyword arguments on Python 3 has to be string. We are dealing with
bytes in our codebase so the keys are also bytes. Done that using
pycompat.strkwargs().
Also after this patch, `hg version` now runs on Python 3.5. Hurray!
In the next patch, we will be creating a bytes version of getopt.getopt() and
doing that will leave getopt as unused import in fancyopts. So before removing
that there are instances in codebase where instead of importing getopt, we
have used fancyopts.getopt. This patch will switch all those cases so that
the next patch can remove the import of getopt from fancyopts without breaking
things.
This allows us to write doctests depending on a ui object, but not on global
configs.
ui.load() is a class method so we can do wsgiui.load(). All ui() calls but
for doctests are replaced with ui.load(). Some of them could be changed to
not load configs later.
Per discussion at 7d927e65eaf2 [1], we need "callcatch" in worker.py. Move
it to scmutil.py to avoid cycles.
Note that dispatch's callcatch handles some additional high-level exceptions
related to config parsing, and commands. Moving them to scmutil will make
scmutil depend on "commands" or require "_formatparse" and "_getsimilar"
(and "difflib") to be moved as well. In the worker use-case, it is forked
when config and commands are fully loaded. So it should not care about those
exceptions.
[1]: https://www.mercurial-scm.org/pipermail/mercurial-devel/2016-August/087116.html
Following the behaviour of Python 3, os.getcwd() return unicodes. We need
bytes version as path variables are bytes in UNIX. Python 3 has os.getcwdb()
which returns current working directory in bytes.
Like rest of the things there in pycompat, like osname, ossep, we need to
rewrite every instance of os.getcwd to pycompat.getcwd to make them work
correctly on Python 3.
Almost all sys.stdin/out/err in hgext/ and mercurial/ are replaced by util's.
There are a few exceptions:
- lsprof.py and statprof.py are untouched since they are a kind of vendor
code and they never import mercurial modules right now.
- ui._readline() needs to replace sys.stdin and stdout to pass them to
raw_input(). We'll need another workaround here.
commands.py is our largest .py file by nearly 2x. Debug commands live
in a world of their own. So let's extract them to their own module.
We start with "debugancestor."
We currently reuse the commands table with commands.py and have a hack
in dispatch.py for loading debugcommands.py. In the future, we could
potentially use a separate commands table and avoid the import of
debugcommands.py.
Add an if True: placeholder for a profiling context manager that
will be added in the next commit, for the purpose of reducing size
of the diff due to trivial indentation changes.
This change should be a no-op.
This should be extremely useful for helping users debug without having
to see their complete configuration.
Shell aliases do not get their expansion logged, because we don't look
and see if we're in a repo before we dive into the execution of a
shell alias. As a result, the ui object doesn't know where to log.
I've caught multiple extensions in the wild lying about being
'internal', so it's time to move the goalposts on people. Goalpost
moving will continue until third party extensions stop trying to
defeat the system.
I've been baffled by this a couple of times (mainly wondering if any
callers of fancyopts.fancyopts that don't use gnu=True exist), so
let's just specify this as a keyword argument to preserve sanity.
And refactor dispatch.py to use it. As you can see, the resulting code
is much simpler.
I was tempted to inline _runcommand as part of writing this series.
However, a number of extensions wrap _runcommand. So keeping it around
is necessary (extensions can't easily wrap runcommand because it calls
hooks before and after command execution).
This makes profiling more flexible since we can now call multiple
functions when a profiler is active. But the real reason for this
is to enable a future consumer to profile a function that returns
a generator. We can't do this from the profiling function itself
because functions can either be generators or have return values:
they can't be both. So therefore it isn't possible to have a generic
profiling function that can both consume and re-emit a generator
and return a value.
We do this for other global command arguments. We don't for --profile
for reasons that are unknown to me. Probably because nobody has needed
it.
An upcoming patch will introduce a new consumer of the profiling
code. It doesn't have access to command line arguments. So let's
set the config option during argument processing.
We also remove a check for "options['profile']" because it is now
redundant.
Currently, profiling code lives in dispatch.py, which is a low-level
module centered around command dispatch. Furthermore, dispatch.py
imports a lot of other modules, meaning that importing dispatch.py
to get at profiling functionality would often result in a module import
cycle.
Profiling is a generic activity. It shouldn't be limited to command
dispatch. This patch moves profiling code from dispatch.py to the
new profiling.py. The low-level "run a profiler against a function"
functions have been moved verbatim. The code for determining how to
invoke the profiler has been extracted to its own function.
I decided to create a new module rather than stick this code
elsewhere (such as util.py) because util.py is already quite large.
And, I foresee this file growing larger once Facebook's profiling
enhancements get added to it.
Before this patch, we may or may not load extensions for shell aliases
depending on whether the command is abbreviated or not.
Loading extensions may have useful side effects to shell aliases. For example,
the pager extension does not work for shell aliases.
This patch removes the code checking shell aliases before loading extensions
to give the user a more consistent experience. It may hurt performance for
shell aliases a bit without chg but the correctness seems worth it. It will
also make the behavior consistent with chg since chg will always load all
extensions before running commands.
The post-* family of hooks will not run in case a command fails (i.e.
raises an exception). This makes it inconvenient to hook into events
such as doing something in case of a failed push.
We catch all exceptions to run the failure hook. I am not sure if this
is too aggressive, but tests apparently pass.
Consumers needing to know if --insecure was used have already
transitioned to using ui.insecureconnections. The previous
patch removed the last meaningful consumer looking for
web.cacerts=!.
