##// END OF EJS Templates
manifest: delay import of `typing.ByteString` for py 3.14 support (issue6940)...
manifest: delay import of `typing.ByteString` for py 3.14 support (issue6940) Since Python 2.7 and 3.5, `typing.ByteString` was defined as an alias for `bytes | bytearray | memoryview`, and `bytes` was also accepted as a shorthand for this, so we have `bytes` sprinkled all over the codebase. But then PEP-688 reversed all of that by deprecating `typing.ByteString` and its successor `collections.abc.ByteString` in Python 3.12 (as well as the `bytes` shorthand)[1], and removing it completely in Python 3.14. That leaves us with a couple of problems, namely defining something useful that spans py3.8-py3.13 and keeps pytype happy, and finding all of the instances where `bytes` doesn't really mean `bytes`. The current successor to all of this is `collections.abc.Buffer` in Python 3.12 (or `typing_extensions.Buffer` in previous versions). However, the current CI does type checking using Python 3.11 (so the former is not avaiable), and pytype has issues with importing `typing_extensions.Buffer`[2]. The good news is we don't need to deal with this mess immediately, since the type annotation evaluation is delayed to the type checking phase, and we're making no effort at supporting it in all supported versions of Python. So by delaying the import of this particular symbol, we can still use it for type checking purposes, but can start assessing Python 3.14 problems without doing a lot of extra work. Putting this on stable will allow people interested in 3.14 to work on it 4-5 extra months earlier (and apparently there's some interest). [1] https://peps.python.org/pep-0688/#no-special-meaning-for-bytes [2] https://github.com/google/pytype/issues/1772

File last commit:

r52729:905bc9d0 default
r53224:0851d94b stable
Show More
readme.rst
57 lines | 1.9 KiB | text/x-rst | RstLexer
Gregory Szorc
wix: functionality to automate building WiX installers...
r42087 WiX Installer
=============
The files in this directory are used to produce an MSI installer using
the WiX Toolset (http://wixtoolset.org/).
The MSI installers require elevated (admin) privileges due to the
installation of MSVC CRT libraries into the Windows system store. See
the Inno Setup installers in the ``inno`` sibling directory for installers
that do not have this requirement.
Requirements
============
Matt Harbison
packaging: drop python27 references from the Windows instructions...
r49971 Building the WiX installer requires a Windows machine.
Gregory Szorc
wix: functionality to automate building WiX installers...
r42087
Matt Harbison
packaging: drop python27 references from the Windows instructions...
r49971 The following system dependencies must be installed:
python-compat: drop support for Python3.6 and 3.7...
r52729 * Python 3.8+ (to run the ``packaging.py`` script)
Gregory Szorc
wix: functionality to automate building WiX installers...
r42087
Building
========
Gregory Szorc
packaging: consolidate CLI functionality into packaging.py...
r43913 The ``packaging.py`` script automates the process of producing an MSI
Gregory Szorc
wix: functionality to automate building WiX installers...
r42087 installer. It manages fetching and configuring non-system dependencies
Matt Harbison
packaging: drop python27 references from the Windows instructions...
r49971 (such as gettext, and various Python packages). It can be run from a
basic cmd.exe Window (i.e. activating the MSBuildTools environment is
not required).
Gregory Szorc
wix: functionality to automate building WiX installers...
r42087
From the prompt, change to the Mercurial source directory. e.g.
``cd c:\src\hg``.
Matt Harbison
packaging: drop python27 references from the Windows instructions...
r49971 Next, invoke ``packaging.py`` to produce an MSI installer.::
Gregory Szorc
wix: functionality to automate building WiX installers...
r42087
Matt Harbison
packaging: replace a documentation reference to `python3` on Windows...
r47179 $ py -3 contrib\packaging\packaging.py \
Matt Harbison
packaging: drop python27 references from the Windows instructions...
r49971 wix --pyoxidizer-target x86_64-pc-windows-msvc
Gregory Szorc
wix: functionality to automate building WiX installers...
r42087
If everything runs as intended, dependencies will be fetched and
configured into the ``build`` sub-directory, Mercurial will be built,
and an installer placed in the ``dist`` sub-directory. The final line
of output should print the name of the generated installer.
Matt Harbison
packaging: drop python27 references from the Windows instructions...
r49971 Additional options may be configured. Run ``packaging.py wix --help``
to see a list of program flags.
Gregory Szorc
wix: functionality to automate building WiX installers...
r42087
Relationship to TortoiseHG
==========================
TortoiseHG uses the WiX files in this directory.
The code for building TortoiseHG installers lives at
Matt Harbison
contrib: migrate off of a couple of bitbucket URLs...
r50068 https://foss.heptapod.net/mercurial/tortoisehg/thg-winbuild and is maintained by
Gregory Szorc
wix: functionality to automate building WiX installers...
r42087 Steve Borho (steve@borho.org).
When changing behavior of the WiX installer, be sure to notify
the TortoiseHG Project of the changes so they have ample time
provide feedback and react to those changes.