annotate tests/test-check-code.t @ 41858:d7dc4ac1ff84

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

#require test-repo

  $ . "$TESTDIR/helpers-testrepo.sh"
  $ check_code="$TESTDIR"/../contrib/check-code.py
  $ cd "$TESTDIR"/..

New errors are not allowed. Warnings are strongly discouraged.
(The writing "no-che?k-code" is for not skipping this file when checking.)

  $ testrepohg locate \
  > -X contrib/python-zstandard \
  > -X hgext/fsmonitor/pywatchman \
  > -X mercurial/thirdparty \
  > | sed 's-\\-/-g' | "$check_code" --warnings --per-file=0 - || false
  Skipping contrib/packaging/inno/build.py it has no-che?k-code (glob)
  Skipping contrib/packaging/packagingutil.py it has no-che?k-code (glob)
  Skipping i18n/polib.py it has no-che?k-code (glob)
  Skipping mercurial/statprof.py it has no-che?k-code (glob)
  Skipping tests/badserverext.py it has no-che?k-code (glob)

@commands in debugcommands.py should be in alphabetical order.

  >>> import re
  >>> commands = []
  >>> with open('mercurial/debugcommands.py', 'rb') as fh:
  ...     for line in fh:
  ...         m = re.match(br"^@command\('([a-z]+)", line)
  ...         if m:
  ...             commands.append(m.group(1))
  >>> scommands = list(sorted(commands))
  >>> for i, command in enumerate(scommands):
  ...     if command != commands[i]:
  ...         print('commands in debugcommands.py not sorted; first differing '
  ...               'command is %s; expected %s' % (commands[i], command))
  ...         break

Prevent adding new files in the root directory accidentally.

  $ testrepohg files 'glob:*'
  .arcconfig
  .clang-format
  .editorconfig
  .hgignore
  .hgsigs
  .hgtags
  .jshintrc
  CONTRIBUTING
  CONTRIBUTORS
  COPYING
  Makefile
  README.rst
  hg
  hgeditor
  hgweb.cgi
  setup.py

Prevent adding modules which could be shadowed by ancient .so/.dylib.

  $ testrepohg files \
  > mercurial/base85.py \
  > mercurial/bdiff.py \
  > mercurial/diffhelpers.py \
  > mercurial/mpatch.py \
  > mercurial/osutil.py \
  > mercurial/parsers.py \
  > mercurial/zstd.py
  [1]

Keep python3 tests sorted:
  $ sort < contrib/python3-whitelist > $TESTTMP/py3sorted
  $ cmp contrib/python3-whitelist $TESTTMP/py3sorted || echo 'Please sort passing tests!'