These are detected as errors since the clean up was done[1] in
the requirements repository.
[1] 314734e938f107cbd5ebcc7af4d9167c11347406
Change-Id: Ib07225b219f6a17decc8eac22fd63a5f19be7138
We also remove these unnecessary linter dependencies from
test-requirements.txt.
Change-Id: I6c3c5fcc329c46054a144557a79c4b3c6ca383b5
Signed-off-by: Stephen Finucane <sfinucan@redhat.com>
ptyz is no longer required in Python >= 3.9 in favor of zoneinfo.
Also tzdata was added to requirements as a runtime dependency of
zoneinfo, which is only available in Python >= 3.9 and is not required
in Python 3.8.
Depends-on: https://review.opendev.org/c/openstack/requirements/+/901119
Change-Id: Icb5bffbeb3da0582332c420ec2b4ceac1a58966b
We removed compatibility with Python 3.8 once but it was added back to
tested runtimes for 2023.2. Thus we have to make sure the code works
with Python 3.8, which was broken by [1].
Note that pytz is added back to requirmenets.txt and is now required
regardless of the python version. This is a short term solution until
we figure out the way to fix the requirement-check job (or we again
remove python 3.8 support).
[1] a326ec5eea
Change-Id: I3b222bb59260dff7a06a5ed48720df3dc8c74ea7
Zoneinfo was introduced within python 3.9.
The support of pytz will be removed within RHEL 10 [1].
2023.2 (bobcat) will move our testing runtime to py3.9 and py3.10
so we want to see pytz removed within this series.
tzdata is required at runtime in our gates, because, by default,
zoneinfo uses the system’s time zone data if available; if no system
time zone data is available, the library will fall back to using the
first-party tzdata package available on PyPI. Apparently our gates have no
time zone data available nor tzdata installed by default because we get the
following error without tzdata installed [3]:
`ModuleNotFoundError: No module named 'tzdata'
So I prefer to add tzdata in our requirements to avoid runtime failure
related to time zone and ensure that time zone are always available.
[1] https://issues.redhat.com/browse/RHEL-219
[2] https://review.opendev.org/c/openstack/governance/+/872232
[3]
https://zuul.opendev.org/t/openstack/build/0a1576775e894b09bc31269fea00ba03/log/job-output.txt#1445`
Depends-on: https://review.opendev.org/c/openstack/requirements/+/875854
Change-Id: I8d87d54f6f5ded8caee6cb780bacb39afea0fea1
A lot of openstack components like:
- solum
- tosca-parser
- heat
- murano
- etc...
reimplement theirs own yaml parser for loading and dumping.
These implementations sometimes forgot to use a safe loader
or safe dumper, our implementation use safe by default.
You can deactive safe by passing the argument is_safe to false when
you call oslo_serialization.yamlutils.load or oslo_serialization.yamlutils.dump.
Change-Id: I63e85a2b4fc999e6acac12ae51c2ab8c64bddbc6
Co-Authored-By: Natal Ngétal <hobbestigrou@erakis.eu>
msgpack is throwing a warning that the unpacker has deprecated the use
of encoding argument. Instead the unpacker uses `raw=False`, which
does an unpack with similar behavior to the old encoding='utf-8'
mechanism.
This will reduce a lot of warning spam for projects using msgpack
such as Keystone. The change to the kwarg "raw" from "bytes_as_raw"
happned between 0.5.1 and 0.5.2. Changing the lower constraint is
required to ensure the new arguments are matching the method
signature.
Change-Id: Iadbee3ec8def9512369a415fb4603dc05d0cbc56
Add ipaddress===1.0.17 to unblock updates of requirements.
Update requirements.txt for msgpack to be 0.5.1 matching
lower-constraints.txt
Change-Id: I94e0dd9dc54822a6fa8daf6d2dce1f203451cb22
Takashi Kajinami