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

r23399:fd5247a8 default
r53224:0851d94b stable
Show More
entrypoint.sh
80 lines | 2.1 KiB | application/x-sh | BashLexer
#!/bin/bash
# This script gets executed on container start. Its job is to set up
# the Mercurial environment and invoke the server.
# Mercurial can be started in two modes.
# If the MERCURIAL_SOURCE environment variable is set and it points to a
# Mercurial source directory, we will install Mercurial from that directory.
# Otherwise, we download the Mercurial source and install it manually.
set -e
SOURCE_DIR=/var/hg/source
INSTALL_DIR=/var/hg/install
REPOS_DIR=/var/hg/repos
HTDOCS_DIR=/var/hg/htdocs
if [ ! -d ${SOURCE_DIR} ]; then
echo "Mercurial source not available at ${SOURCE_DIR}"
echo "You need to mount a volume containing the Mercurial source code"
echo "when running the container. For example:"
echo ""
echo " $ docker run -v ~/src/hg:/${SOURCE_DIR} hg-apache"
echo ""
echo "This container will now stop running."
exit 1
fi
echo "Installing Mercurial from ${SOURCE_DIR} into ${INSTALL_DIR}"
pushd ${SOURCE_DIR}
/usr/bin/python2.7 setup.py install --root=/ --prefix=${INSTALL_DIR} --force
popd
mkdir -p ${HTDOCS_DIR}
# Provide a default config if the user hasn't supplied one.
if [ ! -f ${HTDOCS_DIR}/config ]; then
cp /defaulthgwebconfig ${HTDOCS_DIR}/config
fi
if [ ! -f ${HTDOCS_DIR}/hgweb.wsgi ]; then
cat >> ${HTDOCS_DIR}/hgweb.wsgi << EOF
config = '${HTDOCS_DIR}/config'
import sys
sys.path.insert(0, '${INSTALL_DIR}/lib/python2.7/site-packages')
from mercurial import demandimport
demandimport.enable()
from mercurial.hgweb import hgweb
application = hgweb(config)
EOF
fi
mkdir -p ${REPOS_DIR}
if [ ! -d ${REPOS_DIR}/repo ]; then
${INSTALL_DIR}/bin/hg init ${REPOS_DIR}/repo
chown -R www-data:www-data ${REPOS_DIR}/repo
fi
# This is necessary to make debuginstall happy.
if [ ! -f ~/.hgrc ]; then
cat >> ~/.hgrc << EOF
[ui]
username = Dummy User <nobody@example.com>
EOF
fi
echo "Verifying Mercurial installation looks happy"
${INSTALL_DIR}/bin/hg debuginstall
. /etc/apache2/envvars
echo "Starting Apache HTTP Server on port 80"
echo "We hope you remembered to publish this port when running the container!"
echo "If this is an interactive container, simply CTRL^C to stop."
exec "$@"