There are a handful of modules that have both pure Python and C
extension implementations. Currently, setup.py copies files from
mercurial/pure/*.py to mercurial/ during the install process if C
extensions are not available. This way, "import mercurial.X" will
work whether C extensions are available or not.
This approach has a few drawbacks. First, there aren't run-time checks
verifying the C extensions are loaded when they should be. This could
lead to accidental use of the slower pure Python modules. Second, the
C extensions aren't compatible with PyPy and running Mercurial with
PyPy requires installing Mercurial - you can't run ./hg from a source
checkout. This makes developing while running PyPy somewhat difficult.
This patch implements a PEP-302 import hook for finding and loading the
modules with both C and Python implementations. When a module with dual
implementations is requested for import, its import is handled by our
import hook.
The importer has a mechanism that controls what types of modules we
allow to load. We call this loading behavior the "module load policy."
There are 3 settings:
* Only load C extensions
* Only load pure Python
* Try to load C and fall back to Python
An environment variable allows overriding this policy at run time. This
is mainly useful for developers and for performing actions against the
source checkout (such as installing), which require overriding the
default (strict) policy about requiring C extensions.
The default mode for now is to allow both. This isn't proper and is
technically backwards incompatible. However, it is necessary to
implement a sane patch series that doesn't break the world during
future bisections. The behavior will be corrected in future patch.
We choose the main mercurial/__init__.py module for this code out of
necessity: in a future world, if the custom module importer isn't
registered, we'll fail to find/import certain modules when running
from a pure installation. Without the magical import-time side-effects,
*any* importer of mercurial.* modules would be required to call a
function to register our importer. I'm not a fan of import time side
effects and I initially attempted to do this. However, I was foiled by
our own test harness, which has numerous `python` invoked scripts that
"import mercurial" and fail because the importer isn't registered.
Realizing this problem is probably present in random Python scripts
that have been written over the years, I decided that sacrificing
purity for backwards compatibility is necessary. Plus, if you are
programming Python, "import" should probably "just work."
It's worth noting that now that we have a custom module loader, it
would be possible to hook up demand module proxies at this level
instead of replacing __import__. We leave this work for another time,
if it's even desired.
This patch breaks importing in environments where Mercurial modules
are loaded from a zip file (such as py2exe distributions). This will
be addressed in a subsequent patch.
This should allow easier experimentation with using setuptools in mercurial's
build automation, without breaking anything that currently depends on distutils
behavior
This makes the root install folder (on Windows) nice and tidy. The
only files left in the root folder are:
hg.exe
python27.dll
COPYING.rtf
ReadMe.html
the last of which was probably out-of-date 7 years ago
This will raise a syntax error for people who attempt to use Py2.4,
but that's already going to fail and we have no way to keep other
2.6isms from creeping in since we've removed the check-code rules and
the buildbot.
The last blocker for dropping Python 2.4 was Centos 5. We now provide our own
Mercurial package for Centos 5 with a bundled Python2.7.
I'm therefore happy to officially drop compatibility with Python 2.4 (and
Python 2.5 that nobody really cares about). This open the season for code
cleanup.
It is war's prize to take all vantage.
This lets us iterate manifests in order, but do a _lot_ less work in
the common case when we only care about a few manifest entries.
Many thanks to Mike Edgar for reviewing this in advance of it going
out to the list, which caught many things I missed.
This version of the patch includes C89 fixes from Sean Farley and
many correctness/efficiency cleanups from Martin von
Zweigbergk. Thanks to both!
Some Python installations like the ones available from the optware
project
for the Synology DiskStation NASes don't have that package, which means
running the setup script will crash and exit right away. Instead, we now
just use an empty/fake class for the HackedMingw32CCompiler, which we
likely won't use anyway.
For a Mercurial built on the merge from stable into default right after 3.2.2
was released -- fa2ec68252fb -- the version number produced was "3.2.2+4". This
is potentially misleading, since in reality the built Mercurial includes many
more changes compared to 3.2.2.
Change the versioning scheme so that we take into consideration all the changes
present in the current revision that aren't present in the latest tag. For
fa2ec68252fb the new versioning scheme results in a version number of
"3.2.2+256". This gives users a much better idea of how many changes have
actually happened since the latest release.
Since changessincelatesttag is always greater than or equal to the
latesttagdistance, this will produce version numbers that are always greater
than or equal to the old scheme. Thus there's minimal compatibility risk.
changessincelatesttag gives one a better idea of how much the code has changed
since. Since changessincelatesttag is always greater than or equal to the
latesttagdistance (see previous patch for why), this will always produce
version numbers greater than or equal to the previous scheme.
This helps providing a more consistent user experience on all platforms and
with all packaging.
The exact location of default.d depends on how Mercurial is installed and
whether it is 'frozen'. The exact location should never be relevant to users
and is intentionally not explained in details in the documentation. It will
however always be next to the help and templates files.
Note that setting HGRCPATH also disables these defaults. I don't know if that
should be considered a bug or a feature.
This will give PKI-secure behaviour out of the box, without any configuration.
Setting web.cacerts to any value or empty will disable this trick.
This dummy cert trick only works on OS X 10.6+, but 10.5 had Python 2.5 which
didn't have certificate validation at all.
OS X would offer to expand the zip so the (multi file) installer inside it
could be run ... but that would leave the expanded zip folder around.
Instead, use a .dmg file that automatically will be mounted - that seems more
common on OS X.
Still, there is two levels of levels of clicking before actually launching the
installer. Having a single file installer would be better ... but seems to be
hard. A more feasible improvement would be some fancy layout inside the .dmg .
"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.
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.
This is over twice as fast as the Python dirs code. Upcoming changes
will nearly double its speed again.
perfdirs results for a working dir with 170,000 files:
Python 638 msec
C 244
We give up using CPython's PythonXX.lib import libraries (and Python.h), and
now "manually" call the LoadLibrary() / GetProcAddress() Windows API's instead.
If there is a "hg-python" subdirectory (the canonical directory name for
HackableMercurial's private Python copy) next to the hg.exe, we load the
pythonXX.dll from there (feeding an absolute path to LoadLibrary) and we set
Py_SetPythonHome() to that directory, so that the Python libraries are used
from there as well.
If there is no "hg-python" subdir found next to the hg.exe, we do not feed an
absolute path to LoadLibrary. This continues to allow to find a globally
installed Python DLL, as before this change - that is, without having to edit,
delete, rename, or configure anything.
Note that the hg.exe built is still bound to a *specific* major version of the
pythonXX.dll (e.g. python27.dll). What version it is, is inferred from the
version of the python interpreter that was used when calling setup.py. For
example
C:\python27_x86\python.exe setup.py build_hgexe -i --compiler=mingw32
builds a hg.exe (using the mingw32 tool chain) bound to (x86) Python 2.7. And
C:\python27_x86\python.exe setup.py build_hgexe -i
builds the same using the Microsoft C compiler/linker. (Note that the Microsoft
toolchain combined with x64 CPython can be used to build an x64 hg.exe.)
setup.py is changed to write the name of the pythonlib into the generated header
file "mercurial/hgpythonlib.h", which is #included by exewrapper.c. For a Python
2.7 build, it for example contains:
#define HGPYTHONLIB "python27"
exewrapper.c then uses HGPYTHONLIB for the name of the Python dll to load.
We don't want to track mercurial/hgpythonlib.h, so we add it to .hgignore.
The old calculation code failed to properly identify revs that
weren't tagged, leaving us with a version of "unknown" most of the
time during development.
Not yet used (will be enabled in a later patch).
This patch is a stripped down version of patches originally created by
Bryan O'Sullivan <bryano@fb.com>
This gcc option has been deprecated since at least 2009 (gcc 4.4),
and it causes compilations to fail entirely with gcc 4.6.x.
Upstream distutils bug: http://bugs.python.org/issue12641
