This removes ambiguity as to which modules are being imported, making
import slightly faster as Python doesn't need to test so many
directories for file presence.
All files should already be using absolute imports because mach command
modules aren't imported to the package they belong to: they instead
belong to the "mach" package. So relative imports shouldn't have been
used.
We're about to deploy this to release automation. We might as well have
normal people start using it as well. We could perhaps even have the
extension print out information on how to resume interrupted downloads
someday, so it will pay to have this enabled so they can utilize that
feature some day in the future.
DONTBUILD (NPOTB)
We dropped support for Mercurial 3.0 in version-control-tools. Bump
minimum versions in extensions to reflect this.
We highly recommend people run a modern Mercurial. Bump the minimum
non-legacy version to reflect that.
CLOSED TREE
Backed out changeset 12ce98475c6e (bug 1119980)
Backed out changeset bdb8d05f8870 (bug 1119980)
Backed out changeset a68a18840492 (bug 1119980)
Currently we only mark the version-control-tools repo as needing updating, if
we did not pass a path param to prompt_external_extension(). This is because if
no path is passed, the extension is used from the version-control-tools repo,
and so if _no_ path is passed, it's presumed the extension is external to the
repo. However this is not always the case - eg if we need to specify a specific
file for an extension (vs the entire directory), we have to do so be passing in
the path. We hit this case for reviewboard.
With this change, we always mark the version-control-tools repo as needing an
update, no matter where the extension was located.
mqext was moved into the version-control-tools repo some time ago, but mach
mercurial-setup was still pointing at the old repo location, which is no longer
being updated.
This is needed for compatibility with an upcoming release of
MozillaBuild, which distributes Mercurial as a Python package, not as a
standalone Windows program. As a result, it introduces "hg" into $PATH,
which "which" will happily prefer as the "hg" binary. This upsets
subprocess. So, we explicitly prefer "hg.exe" over "hg".
We could accomplish the same thing by calling which.whichall() and
sorting results. But this is more code and IMO not worth the effort to
implement.
