Pierre-Yves David <pierre-yves.david@fb.com> [Sat, 05 Dec 2015 23:14:49 -0800] rev 27277
localrepo: reinstate localrepo.parents with a deprecation warning
The function was dropped in
3fe8cb40c9c5. This API drop brokes three of my
extensions including some critical to my workflow like tortoisehg. Lets mark
this API for death and give people time to fix their code.
Pierre-Yves David <pierre-yves.david@fb.com> [Sat, 05 Dec 2015 23:34:07 -0800] rev 27276
bookmark: deprecate 'bmstore.write' method
This function does not collaborate with the transaction and must disappear. As
we have likely a lot of third party users, we make it deprecated to let them some
time to upgrade their code.
Thanks goes to Laurent Charignon for cleanup the last remains of the 'write'
method.
Pierre-Yves David <pierre-yves.david@fb.com> [Sat, 05 Dec 2015 23:05:49 -0800] rev 27275
ui: add a 'deprecwarn' helper to issue deprecation warnings
As discussed on the list, we are adding an official way to keep old API around
for a short time in order to help third party developer to catch up. The
deprecated API will issue developer warning (issued by default during test runs)
to warn extensions authors that they need to upgrade their code without
instantaneously breaking tool chains and normal users.
The version is passed as an explicit argument so that developer think about it
and a potential future script can automatically check for it.
This is not build as a decorator because accessing the 'ui' instance will likely
be different each time. The message is also free form because deprecated API are
replaced in a variety of ways. I'm not super happy about the final rendering of
that message, but this is a developer oriented warning and I would like to move
forward.
Pierre-Yves David <pierre-yves.david@fb.com> [Sat, 05 Dec 2015 23:05:33 -0800] rev 27274
ui: add a 'stacklevel' argument to 'develwarn'
This allows helper functions (like deprecation warning) to prepare a devel
warning for higher up in the stack. The argument is named after the one in the
Python's 'warning,warn' function.
Yuya Nishihara <yuya@tcha.org> [Sun, 06 Dec 2015 14:28:35 +0900] rev 27273
import-checker: tell which symbol causes "direct symbol import"
This would be sometimes useful to understand why import-checker.py complains
about it.
Yuya Nishihara <yuya@tcha.org> [Sun, 06 Dec 2015 14:18:19 +0900] rev 27272
import-checker: allow absolute imports of sub modules from local packages
Before this patch, import-checker.py didn't know if a name in ImportFrom
statement are module or not. Therefore, it complained the following example
did "direct symbol import from mercurial".
# hgext/foo.py
from mercurial import hg
This patch reuses the dict of local modules to filter out sub-module names.
Martin von Zweigbergk <martinvonz@google.com> [Fri, 04 Dec 2015 14:24:45 -0800] rev 27271
manifest: use 't' for tree manifest flag
We currently use 'd' to indicate that a manifest entry is a
directory. Let's switch to 't', since that's not a valid hex digit and
therefore easier to spot in the raw manifest data.
This will break any existing repos with tree manifests, but it's still
an experimental feature and there are probably only a few test repos
in existence with 'd' flags.
Pierre-Yves David <pierre-yves.david@fb.com> [Sat, 05 Dec 2015 23:06:03 -0800] rev 27270
test: update the docstring of 'test-devel-warnings.t' extension
We are testing more than just locks now.
Gregory Szorc <gregory.szorc@gmail.com> [Sat, 05 Dec 2015 17:52:50 -0800] rev 27269
setup.py: don't rewrite @LIBDIR@ when creating wheels
This is necessary to produce wheels that install properly. More
details are captured in an in-line comment.
After this patch, produced wheels can be installed via `pip install`
and appear to "just work," including on Windows.
Gregory Szorc <gregory.szorc@gmail.com> [Fri, 04 Dec 2015 00:24:48 -0800] rev 27268
setup.py: attempt to build and install hg.exe on Windows
Currently, packaging Mercurial on Windows will produce a
Scripts\hg Python script and a Scripts\hg.bat batch script. The
py2exe distribution contains a hg.exe which loads a Python
interpretter and invokes the "hg" Python script. Running a
exe directly has benefits over batch scripts because batch
scripts do things like muck around with command arguments.
This patch implements a custom "build_scripts" command which
attempts to build hg.exe on Windows. If hg.exe is built, it is
marked as a "script" file and installed into the Scripts\
directory on Windows. Since hg.exe is redundant and better than
hg.bat, if hg.exe is built, hg.bat is not installed.
Since some environments don't support compiling C programs,
we treat hg.exe as optional and catch failures building it. This
is not ideal. However, I reckon most Windows users will not be
installing Mercurial from source: they will get it from the MSI
installer or via `pip install Mercurial`, which will download a
wheel that has hg.exe in it. So, I don't think this is a big deal.