This closes HTTP responses when no content reads are required, as
when requests are made in streaming mode, ``requests`` doesn't know
whether the caller may intend to later read content from a streamed
HTTP response object and holds the socket open.
Co-authored-by: Adam Turner <9087854+AA-Turner@users.noreply.github.com>
* continuous integration: add comment explaining PYTHONWARNINGS env var to main unit test workflow
* continuous integration: unit test workflow: report-but-do-not-fail
when warnings about pkg_resources deprecation are encountered during
docutils dependency installation
* continuous integration: unit test workflow: instead of reducing the
severity of all DeprecationWarnings during docutils (non-dev)
installation, apply two message filters - one each for the warnings
encountered so far
* continuous integration: unit test workflow: add 'module' and 'line'
fields for warning filters
Ref:
https://docs.python.org/3/library/warnings.html#describing-warning-filters
---------
Co-authored-by: Jean-François B <2589111+jfbu@users.noreply.github.com>
This commit disables Sphinx's localisation features when reproducible
builds are requested, as determined by a non-empty SOURCE_DATE_EPOCH_
environment variable.
The `Reproducible Builds`_ project aims to provide confidence to
consumers of packaged software that the artefacts they're downloading
and installing have not been altered by the environment they were
built in, and can be replicated at a later date if required.
Builds of localised documentation using Sphinx currently account for
a large category of reproducible build testing failures, because the
builders intentionally use varying environment locales at build-time.
This can affect the contents of the ``objects.inv`` file.
During investigation, it turned out that many ``gettext``-localised
values (particularly in Python modules under ``sphinx.domains``) were
being translated at module-load-time and would not subsequently be
re-localised.
This creates two unusual effects:
1. Attempting to write a test case to build the same application in
two different languages was not initially possible, as the
first-loaded translation catalogue (as found in the
``sphinx.locale.translators`` global variable) would remain in-use
for subsequent application builds under different locales.
2. Localisation of strings could vary depending on whether the
relevant modules were loaded before or after the resource
catalogues were populated.
We fix this by performing all translations lazily so that module
imports can occur in any order and localisation of inventory entries
should occur only when translations of those items are requested.
Localisation can then be disabled by configuring the ``gettext``
language to the ISO-639-3 'undetermined' code (``'und'``), as this
should not have an associated translation catalogue. We also want to
prevent ``gettext`` from attempting to determine the host's locale
from environment variables (including ``LANGUAGE``).
.. _SOURCE_DATE_EPOCH: https://reproducible-builds.org/docs/source-date-epoch/
.. _Reproducible Builds: https://www.reproducible-builds.org/
Code related to ``ngettext`` (support for n-ary / plural forms of
translated text) doesn't appear to be used, so this commit cleans up
the code by removing the ``ngettext`` reference.
Detail
------
- ``ngettext`` allows an application to provide a dynamic number
(often a count of items, like '5' in ``the linter produced 5
warnings``) to the translation query so that a plurality-relevant
message can be retrieved from the catalogue.
- ``sphinx`` has previously used this within its own codebase, but no
longer does -- ``babel`` command-line extraction [1] is used to
retrieve translatable resources from the codebase, and extraction
of plural-form keywords is not configured (nor easy to enable, as
far as I could tell).
- As a result it seems like it may make sense to remove the code.
[1]: https://babel.pocoo.org/en/latest/cmdline.html#extract
James AddisonandAdam Turner
