##// END OF EJS Templates
inno: script to automate building Inno installer...
inno: script to automate building Inno installer The official Inno installer build process is poorly documented. And attempting to reproduce behavior of the installer uploaded to www.mercurial-scm.org has revealed a number of unexpected behaviors. This commit attempts to improve the state of reproducibility of the Inno installer by introducing a Python script to largely automate the building of the installer. The new script (which must be run from an environment with the Visual C++ environment configured) takes care of producing an Inno installer. When run from a fresh Mercurial source checkout with all the proper system dependencies (the VC++ toolchain, Windows 10 SDK, and Inno tools) installed, it "just works." The script takes care of downloading all the Python dependencies in a secure manner and manages the build environment for you. You don't need any additional config files: just launch the script, pointing it at an existing Python and ISCC binary and it takes care of the rest. The produced installer creates a Mercurial installation with a handful of differences from the existing 4.9 installers (produced by someone else): * add_path.exe is missing (this was removed a few changesets ago) * The set of api-ms-win-core-* DLLs is different (I suspect this is due to me using a different UCRT / Windows version). * kernelbase.dll and msasn1.dll are missing. * There are a different set of .pyc files for dulwich, keyring, and pygments due to us using the latest versions of each. * We include Tcl/Tk DLLs and .pyc files (I'm not sure why these are missing from the existing installers). * We include the urllib3 and win32ctypes packages (which are dependencies of dulwich and pywin32, respectively). I'm not sure why these aren't present in the existing installers. * We include a different set of files for the distutils package. I'm not sure why. But it should be harmless. * We include the docutils package (it is getting picked up as a dependency somehow). I think this is fine. * We include a copy of argparse.pyc. I'm not sure why this was missing from existing installers. * We don't have a copy of sqlite3/dump.pyc. I'm not sure why. The SQLite C extension code only imports this module when conn.iterdump() is called. It should be safe to omit. * We include files in the email.test and test packages. The set of files is small and their presence should be harmless. The new script and support code is written in Python 3 because it is brand new and independent code and I don't believe new Python projects should be using Python 2 in 2019 if they have a choice about it. The readme.txt file has been renamed to readme.rst and overhauled to reflect the existence of build.py. Differential Revision: https://phab.mercurial-scm.org/D6066

File last commit:

r40329:c303d65d default
r42019:d7dc4ac1 default
Show More
children.py
74 lines | 2.3 KiB | text/x-python | PythonLexer
# Mercurial extension to provide the 'hg children' command
#
# Copyright 2007 by Intevation GmbH <intevation@intevation.de>
#
# Author(s):
# Thomas Arendsen Hein <thomas@intevation.de>
#
# This software may be used and distributed according to the terms of the
# GNU General Public License version 2 or any later version.
'''command to display child changesets (DEPRECATED)
This extension is deprecated. You should use :hg:`log -r
"children(REV)"` instead.
'''
from __future__ import absolute_import
from mercurial.i18n import _
from mercurial import (
cmdutil,
logcmdutil,
pycompat,
registrar,
scmutil,
)
templateopts = cmdutil.templateopts
cmdtable = {}
command = registrar.command(cmdtable)
# Note for extension authors: ONLY specify testedwith = 'ships-with-hg-core' for
# extensions which SHIP WITH MERCURIAL. Non-mainline extensions should
# be specifying the version(s) of Mercurial they are tested with, or
# leave the attribute unspecified.
testedwith = 'ships-with-hg-core'
@command('children',
[('r', 'rev', '.',
_('show children of the specified revision'), _('REV')),
] + templateopts,
_('hg children [-r REV] [FILE]'),
helpcategory=command.CATEGORY_CHANGE_NAVIGATION,
inferrepo=True)
def children(ui, repo, file_=None, **opts):
"""show the children of the given or working directory revision
Print the children of the working directory's revisions. If a
revision is given via -r/--rev, the children of that revision will
be printed. If a file argument is given, revision in which the
file was last changed (after the working directory revision or the
argument to --rev if given) is printed.
Please use :hg:`log` instead::
hg children => hg log -r "children(.)"
hg children -r REV => hg log -r "children(REV)"
See :hg:`help log` and :hg:`help revsets.children`.
"""
opts = pycompat.byteskwargs(opts)
rev = opts.get('rev')
ctx = scmutil.revsingle(repo, rev)
if file_:
fctx = repo.filectx(file_, changeid=ctx.rev())
childctxs = [fcctx.changectx() for fcctx in fctx.children()]
else:
childctxs = ctx.children()
displayer = logcmdutil.changesetdisplayer(ui, repo, opts)
for cctx in childctxs:
displayer.show(cctx)
displayer.close()