Most test scripts use "hg" to interact with a temporary test repository.
However a few tests also want to run hg commands to interact with the local
repository containing the mercurial source code. Notably, many of the
test-check-* tests want to check local files and commit messages.
These tests were previously using the version of hg being tested to query the
source repository. However, this will fail if the source repository requires
extensions or other settings not supported by the version of mercurial being
tested. The source repository was typically initially cloned using the system
hg installation, so we should use the system hg installation to query it.
There was already a helpers-testrepo.sh script designed to help cope with
different requirements for the source repository versus the test repositories.
However, it only handled the evolve extension. This new behavior works with
any extensions that are different between the system installation and the test
installation.
'memoryview' was introduced in Python 2.7. 73ce96f78032 added code
to filterpyflakes.py to ignore "undefined name 'memoryview'" pyflakes
warnings. Since we no longer support <Python 2.7, we can remove this
workaround.
The code under pywatchman used to be excluded from test-check-code and
test-check-pyflakes through the magic string "no-check-code". Now that
test-check-code excludes the pywatchman directory entirely, the directory
should also be excluded from test-check-pyflakes.
As the commit message for the previous changeset says, we wish
for zstd to be a 1st class citizen in Mercurial. To make that
happen, we need to enable Python to talk to the zstd C API. And
that requires bindings.
This commit vendors a copy of existing Python bindings. Why do we
need to vendor? As the commit message of the previous commit says,
relying on systems in the wild to have the bindings or zstd present
is a losing proposition. By distributing the zstd and bindings with
Mercurial, we significantly increase our chances that zstd will
work. Since zstd will deliver a better end-user experience by
achieving better performance, this benefits our users. Another
reason is that the Python bindings still aren't stable and the
API is somewhat fluid. While Mercurial could be coded to target
multiple versions of the Python bindings, it is safer to bundle
an explicit, known working version.
The added Python bindings are mostly a fully-featured interface
to the zstd C API. They allow one-shot operations, streaming,
reading and writing from objects implements the file object
protocol, dictionary compression, control over low-level compression
parameters, and more. The Python bindings work on Python 2.6,
2.7, and 3.3+ and have been tested on Linux and Windows. There are
CFFI bindings, but they are lacking compared to the C extension.
Upstream work will be needed before we can support zstd with PyPy.
But it will be possible.
The files added in this commit come from Git commit
e637c1b214d5f869cf8116c550dcae23ec13b677 from
https://github.com/indygreg/python-zstandard and are added without
modifications. Some files from the upstream repository have been
omitted, namely files related to continuous integration.
In the spirit of full disclosure, I'm the maintainer of the
"python-zstandard" project and have authored 100% of the code
added in this commit. Unfortunately, the Python bindings have
not been formally code reviewed by anyone. While I've tested
much of the code thoroughly (I even have tests that fuzz APIs),
there's a good chance there are bugs, memory leaks, not well
thought out APIs, etc. If someone wants to review the code and
send feedback to the GitHub project, it would be greatly
appreciated.
Despite my involvement with both projects, my opinions of code
style differ from Mercurial's. The code in this commit introduces
numerous code style violations in Mercurial's linters. So, the code
is excluded from most lints. However, some violations I agree with.
These have been added to the known violations ignore list for now.
We've only got one kind of pyflakes failure left in our codebase, so
it's time to switch over to a blacklist-based checking scheme. I've
left in the filtering of two undefined names for now out of paranoia,
but those can probably go too.
pycompat.py includes hack to import modules whose names are changed in Python 3.
We use try-except to load module according to the version of python. But this
method forces us to import the modules to raise an ImportError and hence making
it demandimport unfriendly.
This patch changes the try-except blocks to a single if-else block. To avoid
test-check-pyflakes.t complain about unused imports, pycompat.py is excluded
from the test.
hg does not yet run with py3, so if you try:
./run-tests.py --local test-check-pyflakes.t
... it will try to run the local hg, which does not work
and thus, hg locate will return no output to stdout (and
stderr is sent to /dev/null).
If you do:
./run-tests.py --with-hg=~/bin/hg test-check-pyflakes.t
Then it should work, if your hg is new enough to have
a locate command (hg0.6 does not have locate).
Before this patch, "test-check-pyflakes.t" shows unexpected "undefined
name 'memoryview'" error for "mercurial/util.py" on Python 2.6.x or
earlier, because they don't define symbol 'memoryview'.
This patch introduces excluding patterns into "filterpyflakes.py" to
ignore "undefined name 'memoryview'" pyflakes error on Python 2.6.x or
earlier
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.
- old-style patterns without ^ were getting improperly anchored
- finditer was matching against beginning of line poorly
- \s was matching newlines
- [^x] was matching newlines
so we:
- remove earlier hacks for multiline matching
- fix unified test anchoring by adding .*
- replace \s with [ \t]
- replace [^x] with [^\nx]
- force all matches into multiline mode so ^ anchors work
This uncovers a number of test issues that are then repaired.
