##// 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:

r53164:81e59988 stable
r53224:0851d94b stable
Show More
build-linux-wheels.sh
47 lines | 1.3 KiB | application/x-sh | BashLexer
#!/bin/bash
# Intended to run within docker using image:
#
# registry.heptapod.net/mercurial/ci-images/core-wheel-x86_64-c:v3.0
#
# we might want to factor most of this with the associated mercurial-core CI
# definition. (i.e. move this script into a place where the CI can directly call it for its purpose)
set -e -x
PYTHON_TARGETS="cp38-cp38 cp39-cp39 cp310-cp310 cp311-cp311 cp312-cp312 cp313-cp313"
export MERCURIAL_SETUP_FORCE_TRANSLATIONS=1
# We need to copy the repository to ensure:
# (1) we don't wrongly write roots files in the repository (or any other wrong
# users)
# (2) we don't reuse pre-compiled extension built outside for manylinux and
# therefor not compatible.
cp -r /src/ /tmp/src/
cd /tmp/src/
# clear potentially cached artifact from the host
# (we could narrow this purge probably)
hg purge \
--ignored \
--no-confirm
if [ ! -e /src/dist/ ]; then
mkdir -p /src/dist
chown `stat /src/ -c %u:%g` /src/dist/
fi
for py in $PYTHON_TARGETS; do
echo 'build wheel for' $py
# cleanup any previous wheel
tmp_wd="/tmp/wheels/$py/repaired"
rm -rf $tmp_wd
mkdir -p $tmp_wd
# build a new wheel
contrib/build-one-linux-wheel.sh $py $tmp_wd
# fix the owner back to the repository owner
chown `stat /src/ -c %u:%g` $tmp_wd/*.whl
mv $tmp_wd/*.whl /src/dist/
done