Gregory Szorc <gregory.szorc@gmail.com> [Fri, 08 Mar 2019 10:25:05 -0800] rev 41927
wix: remove sphinx and dependencies
Sphinx was cargo culted into our install environment as part of
emulating TortoiseHG's behavior.
THG seems to install Sphinx in order to generate THG specific
documentation.
We don't appear to need Sphinx or any of its dependencies in
the official WiX installers. So remove it.
This shaves ~1MB off the size of the MSI installers.
.. bc::
The Windows MSI installers no longer include the Python
sphinx package and its various dependencies.
Differential Revision: https://phab.mercurial-scm.org/D6099
Gregory Szorc <gregory.szorc@gmail.com> [Fri, 08 Mar 2019 10:48:22 -0800] rev 41926
wix: functionality to automate building WiX installers
Like we did for Inno Setup, we want to make it easier to
produce WiX installers. This commit does that.
We introduce a new hgpackaging.wix module for performing
all the high-level tasks required to produce WiX installers.
This required miscellaneous enhancements to existing code in
hgpackaging, including support for signing binaries.
A new build.py script for calling into the module APIs has been
created. It behaves very similarly to the Inno Setup build.py
script.
Unlike Inno Setup, we didn't have code in the repo previously
to generate WiX installers. It appears that all existing
automation for building WiX installers lives in the
https://bitbucket.org/tortoisehg/thg-winbuild repository - most
notably in its setup.py file. My strategy for inventing the
code in this commit was to step through the code in that repo's
setup.py and observe what it was doing. Despite the length of
setup.py in that repository, the actual amount of steps required
to produce a WiX installer is actually quite low. It consists
of a basic py2exe build plus invocations of candle.exe and
light.exe to produce the MSI.
One rabbit hole that gave me fits was locating the Visual Studio
9 C Runtime merge modules. These merge modules are only present
on your system if you have a full Visual Studio 2008 installation.
Fortunately, I have a copy of Visual Studio 2008 and was able
to install all the required updates. I then uploaded these merge
modules to a personal repository on GitHub. That is where the
added code references them from. We probably don't need to
ship the merge modules. But that is for another day.
The installs from the MSIs produced with the new automation
differ from the last official MSI in the following ways:
* Our HTML manual pages have UNIX line endings instead of Windows.
* We ship modules in the mercurial.pure package. It appears the
upstream packaging code is not including this package due to
omission (they supply an explicit list of packages that has
drifted out of sync with our setup.py).
* We do not ship various distutils.* modules. This is because
virtualenvs have a custom distutils/__init__.py that automagically
imports distutils from its original location and py2exe gets
confused by this. We don't use distutils in core Mercurial and
don't provide a usable python.exe, so this omission should be
acceptable.
* The version of the enum package is different and we ship
an enum.pyc instead of an enum/__init__.py.
* The version of the docutils package is different and we
ship a different set of files.
* The version of Sphinx is drastically newer and we ship a
number of files the old version did not. (I'm not sure why
we ship Sphinx - I think it is a side-effect of the way the
THG code was installing dependencies.)
* We ship the idna package (dependent of requests which is a
dependency of newer versions of Sphinx).
* The version of imagesize is different and we ship an
imagesize.pyc instead of an imagesize/__init__.pyc.
* The version of the jinja2 package is different and the sets
of files differs.
* We ship the packaging package, which is a dependency for Sphinx.
* The version of the pygments package is different and the sets
of files differs.
* We ship the requests package, which is a dependency for Sphinx.
* We ship the snowballstemmer package, which is a dependency for
Sphinx.
* We ship the urllib3 package, which is a dependency for requests,
which is a dependency for Sphinx.
* We ship a newer version of the futures package, which includes a
handful of extra modules that match Python 3 module names.
# no-check-commit because foo_bar naming
Differential Revision: https://phab.mercurial-scm.org/D6097
Gregory Szorc <gregory.szorc@gmail.com> [Thu, 07 Mar 2019 15:37:42 -0800] rev 41925
wix: move contrib/wix to contrib/packaging/wix
We're trying to consolidate all our packaging code into
contrib/packaging. Let's move the WiX files there.
Differential Revision: https://phab.mercurial-scm.org/D6096
Gregory Szorc <gregory.szorc@gmail.com> [Fri, 08 Mar 2019 10:33:05 -0800] rev 41924
wix: remove hg.cmd
This file is not referenced anywhere AFAICT.
Differential Revision: https://phab.mercurial-scm.org/D6095
Gregory Szorc <gregory.szorc@gmail.com> [Thu, 07 Mar 2019 14:02:02 -0800] rev 41923
setup: include hgext3rd package in py2exe builds
This is a core Mercurial package and we should always ship it.
Differential Revision: https://phab.mercurial-scm.org/D6094
Gregory Szorc <gregory.szorc@gmail.com> [Thu, 07 Mar 2019 13:47:28 -0800] rev 41922
setup: properly install build_hgextindex for py2exe builds
Because the hgbuild class has a private copy of build.sub_commands,
modifying build.sub_commands from this code effectively resulted
in a no-op. Registering the sub-command on hgbuild actually results
in the sub-command running when building Mercurial.
Differential Revision: https://phab.mercurial-scm.org/D6093
Gregory Szorc <gregory.szorc@gmail.com> [Thu, 07 Mar 2019 12:15:32 -0800] rev 41921
setup: configure py2exe config via environment variables
The Inno Setup and WiX installers ship a different set of packages
with py2exe builds. And there are multiple WiX installer variants
(e.g. TortoiseHG).
Since there are multiple variants of py2exe configs and they
can be defined by entities not in our repository, let's
provide a mechanism for setup.py to supplement behavior via
environment variables. This is slighly less hacky than a setup.cfg
file IMO since the caller doesn't need to worry about mutating
global state of the source directory.
Differential Revision: https://phab.mercurial-scm.org/D6092
Gregory Szorc <gregory.szorc@gmail.com> [Thu, 07 Mar 2019 15:43:54 -0800] rev 41920
packaging: extract py2exe functionality to own module
py2exe builds are shared between Inno Setup and WIX. We'll
want the logic for performing py2exe builds to be reusable
across the code for both installers.
This commit extracts the py2exe-specific functionality into
its own module.
There's definitely room to customize things further. This will
be done in future commits, as necessary. (I'm not even sure what
customizations WIX will require yet. Presumably a lot.)
Differential Revision: https://phab.mercurial-scm.org/D6091
Gregory Szorc <gregory.szorc@gmail.com> [Thu, 07 Mar 2019 10:49:59 -0800] rev 41919
packaging: extract python exe info to own function
This is generic functionality. We'll need it for WIX.
As part of the port, we expose the full version and return
the data as a dict.
Differential Revision: https://phab.mercurial-scm.org/D6090
Gregory Szorc <gregory.szorc@gmail.com> [Thu, 07 Mar 2019 10:36:20 -0800] rev 41918
packaging: don't use temporary directory
We were no longer doing anything with it after extracting
virtualenv and py2exe to the build directory.
Differential Revision: https://phab.mercurial-scm.org/D6089
Gregory Szorc <gregory.szorc@gmail.com> [Thu, 07 Mar 2019 10:35:20 -0800] rev 41917
packaging: extract virtualenv and py2exe to build directory
The build directory is essentially a cache. We can extract
the virtualenv and py2exe package sources to this directory.
Differential Revision: https://phab.mercurial-scm.org/D6088
Gregory Szorc <gregory.szorc@gmail.com> [Thu, 07 Mar 2019 15:43:14 -0800] rev 41916
packaging: move Inno Setup core logic into a module
Aspects of building the Inno Setup and WIX installers are shared.
It will make sense for them to share code.
Plus, having code in a reusable library (as opposed to a standalone
script) is just a better approach.
This commit moves the core logic to build the Inno Setup installer
into the hgpackaging package. inno/build.py is now a simple frontend
script that calls into a module to do the bulk of the work.
As part of this change, I also found a typo in build() where it was
referencing "iscc" instead of "iscc_exe." Because "iscc" was in
the global scope via the only caller, things just happened to work
before. Another benefit of always using functions and not putting
global code for __main__ in the same file as library code.
Differential Revision: https://phab.mercurial-scm.org/D6087
Gregory Szorc <gregory.szorc@gmail.com> [Thu, 07 Mar 2019 10:22:09 -0800] rev 41915
packaging: move find_vc_runtime_files() into hgpackaging.util
In preparation for moving the bulk of the Inno Setup code into
hgpackaging.
Differential Revision: https://phab.mercurial-scm.org/D6086
Gregory Szorc <gregory.szorc@gmail.com> [Thu, 07 Mar 2019 10:20:37 -0800] rev 41914
packaging: move DOWNLOADS dict to hgpackaging.downloads
We'll want to keep state in sync between multiple packaging tools.
It makes sense to share a central data structure defining downloads.
We also change the function to return the downloads entry so
callers don't have to access the global DOWNLOADS in the new
location.
Differential Revision: https://phab.mercurial-scm.org/D6085