Python 2.6 introduced the "except type as instance" syntax, replacing
the "except type, instance" syntax that came before. Python 3 dropped
support for the latter syntax. Since we no longer support Python 2.4 or
2.5, we have no need to continue supporting the "except type, instance".
This patch mass rewrites the exception syntax to be Python 2.6+ and
Python 3 compatible.
This patch was produced by running `2to3 -f except -w -n .`.
Before this patch, there was no handy way to investigate the reason why
extension couldn't be loaded.
If ui.debug is set, tracebacks of both "hgext.foo" and "foo" are displayed
because the first ImportError could occur at very deep dependency module.
It was reported that enabling pager without color could cause a hang.
Inserting print statements revealed that the callbacks in
extensions._aftercallbacks were being invoked twice.
extensions.loadall can be called multiple times. If entries in
extensions._aftercallbacks linger between calls, this could result
in double execution of the callbacks. This can lead to unwanted
behavior.
The reproduce steps in the bug seem to only occur when the output of
a command is less than the size of the current screen. This is not
something that can easily be tested. I verified the test case works
with this patch and that pager and color interaction continues to
work. Since we have no existing automated tests for pager, this sadly
appears to be the best testing I can do.
We use partial function application for wrapping existing Mercurial functions,
and it's implemented separately each time. This patch extracts the partial
application into a new bind() function that can be used on its own by extensions
when appropriate.
In particular, the evolve extension needs to wrap functions in the various
bundle2 processing dictionaries, which the pre-existing methods don't support.
Mercurial uses a synopsis string and the docstring of a command for the
command's help output. Today there is no way for an extension that adds
functionality to a command to extend either of these help strings.
This patch enables appending to both the doctring and the synopsis, and adds
a test for this functionality. Example usage is shown in the test and is also
described in the docstring of extensions.wrapcommand().
An upcoming patch will introduce a dependency between the color and
pager extensions. To prepare for this, we teach extensions how to
register callbacks that can execute when another extension loads.
This patch is based on code provided by Matt Mackall. But significant
parts have changed (such as the ability to register multiple callbacks
and the change in behavior to always call a callback).
I believe that always firing the callback is a good practice. I think
the common use for this feature will be for extensions to say "run this
one-time setup code, after this other extension if possible." Always
running the callback will facilitate this.
This was introduced way back in 2006 (rev e8e3582d6f80) as sys.exit(0) if
loading an extension failed when --traceback was on, then at some point morphed
into a 'return 1' in a function that otherwise returns nothing.
At this point, if ui.traceback is enabled and if loading an extension fails for
whatever reason, including one as innocent as it not being present, we leave
any extensions loaded so far in a bogus half-initialized state. That doesn't
really make any sense.
"make clean" already removed __index__.py[cdo], but not the __index__.py
(automatically generated by "python setup.py build_hgextindex").
"setup.py build_hgextindex" did not generate a new index if file
__index__.py[cdo] already existed, because if __index__.py was removed,
the compiled file containing the old information was imported and used.
Generate an empty file (with a new timestamp to generate a new .py[cdo])
instead and make mercurial.extensions ignore the unset docs attribute.
One of the problems was a failed test-help.t, to reproduce:
$ rm hgext/__index__.py*
$ echo 'docs = {"mq": "dummy"}' > hgext/__index__.py
$ make test-help.t
With this a "make clean" or "python setup.py build_hgextindex" helps.
Fixes same issue as 3dadbacb6aa4 but now works on Windows too.
With this patch a trailing backward slash won't prevent the extension from
being found on Windows, and we continue to support any combination of forward
and back slashes within the path.
This extension has always had correctness issues and has been
unmaintained for years. It is now removed in favor of the third-party
hgwatchman which is maintained and appears to be correct.
Users with inotify enabled in their config files will fall back to
standard status performance.
Before this patch, "extensions.extensions()" always lists up all
loaded extensions. So, commands handling multiple repositories at a
time like below enable extensions unexpectedly.
- clone from or push to localhost: extensions enabled only in the
source are enabled also in the destination
- pull from localhost: extensions enabled only in the destination
are enabled also in the source
- recursive execution in subrepo tree: extensions enabled only in
the parent or some of siblings in the tree are enabled also in
others
In addition to it, extensions disabled locally may be enabled
unexpectedly.
This patch checks whether each of extensions should be listed up or
not, if "ui" is specified to "extensions.extensions()", and invokes
"reposetup()" of each extensions only for repositories enabling it.
Before this patch, "hg help -k KEYWORD" fails, if there is the
extension of which name includes ".", because "extensions.load()"
invoked from "help.topicmatch()" fails to look such extension up, even
though it is already loaded in.
"help.topicmatch()" invokes "extensions.load()" with the name gotten
from "extensions.enabled()". The former expects full name of extension
(= key in '[extensions]' section), but the latter returns names
shortened by "split('.')[-1]". This difference causes failure of
looking extension up.
This patch adds "shortname" argument to "extensions.enabled()" to make
it return shortened names only if it is True. "help.topicmatch()"
turns it off to get full name of extensions.
Then, this patch shortens full name of extensions by "split('.')[-1]"
for showing them in the list of extensions.
Shortening is also applied on names gotten from
"extensions.disabled()" but harmless, because it returns only
extensions directly under "hgext" and their names should not include
".".
With the addition of the websub filter extension this extension is no longer
needed. We maintain a sort of backwards compatibility by reading the [interhg]
section and using it as we would use the [websub] section.
When loading a python hook with file syntax fails, there is no
information that this happened while loading a hook. When the python
file does not exist even the file name is not printed. (Only that a
file is missing.)
This patch adds this information and a test for loading a non existing file and
a directory not being a python module.
This is handy if hgext.foo exists but has a bogus "import blah":
previously we just discarded the "No module named blah" error. Now at
least you can see it with --debug. Not perfect, but better than
nothing.
extensions that depend on other extensions (such as record) use this pattern
to check if the dependant extension is available:
try:
mq = extensions.find('mq')
except KeyError:
return
but since if an error occurs while loading an extension it leaves its entry
in the _extensions map as None, we want to raise in that situation too.
(rather than adding another check if the return value is None)
Invalid extensions in hgext/ could in some cases cause a crash when searching
for unknown commands in disabled extensions.
With this change we issue a warning if extracting commands from the extensions
fails. Traceback is available on request.
Reported on https://bugzilla.redhat.com/show_bug.cgi?id=663183 with forest.py.
Makes extensions.load return the module that
it has loaded.
This is done so that callers can get information on this module, which
e.g. can be used for generating docs.
Instead, all extensions should use the "dynamic subclass" trick:
subclass repo.__class__ and then replace repo.__class__ with your new
subclass. This avoids conflicts that happen when one extension uses
wrapfunction and another uses subclassing to extend the same method of
localrepository.
Before a command is declared unknown, each extension in hgext is searched,
starting with hgext.<cmdname>. If there's a matching command, a help message
suggests the appropriate extension and how to enable it.
Every extension could potentially be imported, but for cases like rebase,
relink, etc. only one extension is imported.
For the case of "hg help disabledext", if the extension is in hgext, the
extension description is read and a similar help suggestion is printed.
No extension import occurs.
previously uisetup() was invoked by extensions.loadall(), but
extsetup() was by _dispatch().
there's no need to split them because we have nothing to do
between uisetup() and extsetup().
this fixes issue1824 indirectly.
Extensions are now loaded with a call-graph like this:
dispatch._dispatch
extensions.loadall
extensions.load
# add foo module to extensions._extensions
extensions.load
# add bar module to extensions._extensions
foo.uisetup(ui)
bar.uisetup(ui)
foo.extsetup()
bar.extsetup()
commands.table.update(foo.cmdtable)
commands.table.update(bar.cmdtable)
hg.repository
foo.reposetup(ui, repo)
bar.reposetup(ui, repo)
The uisetup calls could easily be moved out to dispatch._dispatch, but
have been kept in extensions.loadall since at least TortoiseHg calls
extensions.loadall and expects it to call uisetup.
The extensions.load function called uisetup. It now has an unused ui
argument which has been kept for backwards compatibility.
enabled used to be a boolean, and somehow that bit of code inadvertently
slipped through during a refactoring. Effectively dead code, as the
condition can never be triggered.
Temporary workaround for issue1708: on win32 with py2exe, hgext is distributed
inside a zipped file (which anyway does not contain the py files from which we
ought to extract the documentation strings), which raises a WindowsError
(subclasses OSError).
This means that on such platforms the list of disabled extensions won't be
available. Real fix postponed for after Mercurial 1.3.
