hgtools

hgtools builds on the setuptools_hg plugin for setuptools. It provides classes for inspecting and working with repositories in the Mercurial version control system.

hgtools provides a plugin for setuptools that enables setuptools to find files under the Mercurial version control system.

The classes provided by hgtools are designed to work natively with the Mercurial Python libraries (in process) or fall back to using the command-line program hg(1) if available. The command-line support is especially useful inside virtualenvs that don't have access to a system-wide installed Mercurial lib (i.e. when the virtualenv was created with --no-site-packages).

Note:

The setuptools feature

You can read about the setuptools plugin provided by hgtools in the setuptools documentation. It basically returns a list of files that are under Mercurial version control when running the setup function, e.g. if you create a source and binary distribution. It's a simple yet effective way of not having to define package data (non-Python files) manually in MANIFEST templates (MANIFEST.in).

Usage

Here's an example of a setup.py that uses hgtools:

from setuptools import setup, find_packages
setup(
 name="HelloWorld",
 version="0.1",
 packages=find_packages(),
 setup_requires=["hgtools"],
)

If you run the setup.py above, setuptools will automatically download setuptools_hg to the directory where the setup.py is located at (and won't install it anywhere else) to get all package data files from the Mercurial repository.

Options

Set the HG_SETUPTOOLS_FORCE_CMD environment variable before running setup.py if you want to enforce the use of the hg command (though it will then fall back to the native libraries if the command is not available or fails to run).

What is new in this release:

• Restored Python 2.6 compatibility in reentry module.

What is new in version 2.0.3:

• Issue #12: Suppress exceptions besides ImportError when importing Mercurial modules.

What is new in version 2.0.2:

• Force hg log and hg parents to use the defaults style for output. Otherwise, the parsing code fails to identify the tags. Also, reset the 'default.log' value in case a user has an alias for hg log in his .hgrc. (For example, some use log=-G to force the graph output). Thanks to dc for the patch.

What is new in version 2.0.1:

• Fixed issue #10 where hgtools would not parse setup.cfg properly if the Python 3 configparser backport was installed on Python 2.

What is new in version 2.0:

• Refactored HGRepoManager to better support multiple tags:
• - `.get_tag` replaced by `.get_tags`, which returns a set of tags for a specific revision. This is currently a set because mercurial does not retain any meaningful order of the tags.
• - `.get_tags` replaced by `.get_repo_tags`.
• - `.get_parent_tag` replaced by `.get_parent_tags`.
• - added `.get_parents` which returns the revision(s) of the specified revision.
• Removed support for older versions of mercurial (LegacyLibraryManager).
• The subprocess manager is now the default. The HGTOOLS_FORCE_CMD variable no longer has any effect on hgtools.
• Version detection now resolves multiple tags on the same revision by choosing the greatest version.

What is new in version 1.2.1:

• Fix issue #9 - The repo managers and thus the setuptools plugin will no longer find files that aren't in the location specified. The LibraryManagers already will throw an error in this case, but now the SubprocessManager does what's best and only returns files relative to the location.

What is new in version 1.2:

• Implemented the version_handler version parameter. Fixes #5.
• If multiple tags are given for a revision, the last tag is used instead of the first.

What is new in version 1.1.6:

• More aggressively construct a the environment when running hg in a subprocess. Fixes another manifestation of #7. Thanks whit537.

What is new in version 1.1.2:

• Restored Python 2.5 compatibility.

Requirements:

• Python