The intent here is to get away from relying on system python (which is going
away in 10.16), so that an installer can easily be built to work on multiple
versions of the OS. 10.9 was chosen as the minimum platform here because that's
the SDK needed to notarize, and also what the binary python installer targets.
A lot of this was adapted from the script that builds the TortoiseHg DMG.
There's a useful thg customization (not duplicated here), which extends
sys.path to include $HOME/Library/Python/2.7/lib/python/site-packages, because
there's no way to add to the bundled python after the app is signed. As it
stands now, this installation won't see that, but does see
$HOME/.local/lib/python2.7/site-packages, and the bundled pip will install
there with --user. It does seem like only seeing the second --user location
will get confusing, especially since the current behavior is that
pip install --user ... just works for pip in PATH.
The prerequisite is to have python3 to run the script, and a working python2
with docutils installed to feed to the script. (The latter is used to build and
install the documentation for Mercurial without polluting the python distro to
be packaged, so maybe we can use python3 there.)
The general flow is to download, build and install OpenSSL off to the side, and
then use that to download, build and install Python to a separate staging area.
The certifi package is bundled for the root certificates. I'm not an expert in
what OpenSSL compilation options should be used, so if there's a way to tighten
things up, let me know.
I don't like how the other packaging scripts assume an existing path on the
system, so this uses the build directory to stage the Python and OpenSSL builds.
The existing system python installer stages in build/mercurial, but this
builds Mercurial into the staged python directory. (That path includes version
info, so it shouldn't be much to add python3 support and build both at the same
time.) I also wasn't sure where to stash the downloads (they seem somewhat
useful to cache), so I stuffed them into the packages directory (which gets
clobbered by make clean).
To distinguish from the system python installer (and with an eye towards
python3), -py2.7 is added after the Mercurial version to the file name.
Altogether, this takes about 10 minutes to build on a 2018 Mac Mini.
There's additional followup work to do, in addition to the obvious py3 support-
the readme still mentions depending on system python, and this could probably be
driven by the makefile as a separate target. It should be trivial to sign the
binaries and installer, and slightly less trivial to notarize the *.pkg, but
definitely doable. The files in the final *.pkg can be listed like so:
pkgutil --payload-files dist/Mercurial-*.pkg
Looking at that, there's probably a bunch of junk that can be removed:
- include/
- distutils/tests/
- lib-tk/test/
- ctypes/test/,
- unittest
- test
- lib2to3
- idle
- pydoc
I didn't see config options for that, and maybe it isn't worth it. The
installer ends up around 39MB.
1.0.2u is out and should be used.