Requirements haven't been centrally managed for a long time now. Remove
the tool.
Change-Id: I5689985fd8ab2a061c04776c5320188343b2f077
Signed-off-by: Stephen Finucane <stephenfin@redhat.com>
Sometimes we have to require a specific library in certain python
versions only.
In oslo and a few other projects, we are now replacing pytz by built-in
zoneinfo[1] to reduce 3rd party dependency, but zoneinfo is not
available in python < 3.9 and pytz is still required in python < 3.9.
In addition we need tzdata when zoneinfo is used, which means we need
tzdata only in python >= 3.9.
However these updates are currently prohibited by requirement check
because pytz in the global requirement does not contain python version
marker.
This change allows having a local requirement with python marker along
with the corresponding global requirement without python marker to
support such usage.
[1] https://review.opendev.org/c/openstack/oslo.utils/+/897623
Change-Id: I2bd5671962b3ca1abac91c2afba6e2c566616390
horizon does not support setuptools 67.3.1 and it broke Kolla
Horizon container builds. We recently cut a new release of Xstatic
[1] which may fix this setuptools issue. So this patch bump the
Xstatic version to 1.0.3 to fix setuptools issue.
[1] 5cd7a23470
Related-Bug: #2007574
Change-Id: Icdeb56c9890132b19bf65934bbee135df56d0341
hacking 6.0.0 was released and this now detects a line that is too long,
but went unnoticed before.
Signed-off-by: Dr. Jens Harbott <harbott@osism.tech>
Change-Id: Ia6bcf800a284284e88610aad2edd1d60b75142e6
Probably with the latest virtualenv [1] (which bundles setuptools), the
unit tests started to fail with this error:
File "/home/zuul/src/opendev.org/openstack/requirements/.tox/py310/lib/python3.10/site-packages/pkg_resources/_vendor/packaging/requirements.py", line 37, in __init__
raise InvalidRequirement(str(e)) from e
pkg_resources.extern.packaging.requirements.InvalidRequirement: Expected end or semicolon (after version specifier)
lesscpy>=0.9h
It seems that the parser have become more strict and now it does not
accept other than 0.9a, 0.9b (alpha, beta) releases when parsing
constraints. This patch updates the global requirements test file to
not break the parser.
Also the test_match_without_python3_markers test caused the same error
(with: withmarker>=1.5') and needed an update.
[1] virtualenv (20.19.0) released at Tue, 07 Feb 2023 20:16:53 GMT
Change-Id: Ia2ba3f38a83216abc430ed754bb7d8cbe8c564d3
When we call this from playbooks/files/project-requirements-change.py
we pass in a list[1]. Update the tests to use a list as well.
[1] built with list( dict().keys() )
Change-Id: I3b359a4afc24a7d0069a3531a1d69f87795af115
In change I85501b4bff97d1c1e1873c3329ef998a8e501134, we added the
ability for stdlib backport-style libraries to have different version
specifiers (i.e. 'python_version<=3.9') from what we define in our
global requirements file. At least, that was the intention. However, we
used a regex that wouldn't actually work since it was checking for
Python versions greater than or equal to rather than the inverse. Fix
the regex, adding tests in the process (like we should have done last
time) to prove that things actually work now.
While we're here, add some whitespace and test docstrings to make the
whole thing a little more readable.
Change-Id: I6a8566d086761148d2e7a8e8f8288b2b0e447d08
Signed-off-by: Stephen Finucane <stephenfin@redhat.com>
Move the library names that we are flexible with - backports from the
std.lib - from a hard coded list in code into a txt file
Change-Id: I414f7c386b838248f45fbce003a64d0c83a9919c
There are a number of backport packages in place for packages in stdlib
that are still evolving. One such package is 'importlib-metadata' which
is a backport of 'importlib.metadata'. The README [1] for this package
shows a mapping of versions of the 'importlib-metadata' third party
library to versions of stdlib 'importlib.metadata':
importlib_metadata stdlib
4.8 3.11
4.4 3.10
1.4 3.8
A project may want to use a shiny new feature only found in the Python
3.11 stdlib version while continuing to support Python 3.8, 3.9 and
3.10. If so, they could specify something like so:
importlib-metadata>=4.8;python_version<3.11
Meanwhile, other packages might require features found in the Python
3.10 stdlib version. They would want to specify something like so:
importlib-metadata>=4.4;python_version<3.10
Currently this is not possible as it is not possible to specify
arbitrary 'python_version' markers. Since 'importlib-metadata' does not
have a 'python_version' marker in 'global-requirements.txt' (not since
change I5febaed02e95ff27accd946abc32f3bcbb1a5ead anyway), both projects
would have to specify
importlib-metadata>={required_version}
Which means they'll use importlib-metadata even where they don't need
it.
Fix this issue by allowing a list of particular modules to specify a
project-specific 'python_version' marker. Currently this list only
includes 'importlib-metadata', but in the future we may wish to enhance
it to include other rolling backport libraries (e.g. mock).
[1] https://pypi.org/project/importlib-metadata/
Change-Id: I85501b4bff97d1c1e1873c3329ef998a8e501134
Signed-off-by: Stephen Finucane <stephenfin@redhat.com>
- auto detect python paths (which)
- make it possible to call `tox -e generate` w/o extra args
- update list of pythons to include currently supported versions
Change-Id: Ib727242c1aba8597389259d8dbacba7194f9f0d6
If local exclusions are not a subset of global exclusions, we probably
want to identify any item in local exclusions that are not in global
exclusions, instead of the opposite.
Change-Id: Id8e5a423288ac6db3b836ae553d766e5f04b4dec
Karbor is being retired this cycle so it makes sense to
stop syncing its deliverables requirements.
Change-Id: I729ea78158fa49fc641deb93517d314bc4f13ee5
Recent setuptools include updated vendored pkg_resource that changed
the exception that we need to expect from them. Leave in the old
version, too, for backwards compatibility.
Change-Id: I5bb01fb21982fb8757e925659ad206a15a79f799
The gate nodes no longer have the virtualenv package globally installed
and available, resulting in our nightly job failing with the error:
FileNotFoundError: [Errno 2] No such file or directory: 'virtualenv'
To get around this, this patch updates our generate.py code to use the
venv module that is part of the standard lib in Python 3.3 and later.
Change-Id: I128ce15a1b6ce885dacae4ecd160f5892215683b
Signed-off-by: Sean McGinnis <sean.mcginnis@gmail.com>
The mock third party library was needed for mock support in py2
runtimes. Since we now only support py36 and later, we can use the
standard lib unittest.mock module instead.
Change-Id: Ib4184a05e753c3d1368167b91fc43bcc64a176c3
The method readfp is deprecated and will be removed in future versions.
Use read_file method instead.
Change-Id: I706e73505666e27dc409182db317f05284e6fe85
For projects that have gone Python 3, having to keep the
'python_version' specifiers can add otherwise unnecessary noise. Special
case these until such a time as Python 2.7 is history and we can drop
all these Python version specifiers.
Change-Id: Ie6dba8bc78dcd5fa95c7ac15b0a3770cdef8ad95
Signed-off-by: Stephen Finucane <sfinucan@redhat.com>
Co-Authored-By: Zane Bitter <zbitter@redhat.com>
Before doing any work on this, let's use some more meaningful names.
Change-Id: I640290359c0c15035187a62da1bc57dba5912b05
Signed-off-by: Stephen Finucane <sfinucan@redhat.com>
Ussuri and later will be Python 3 only. This updates our requirements
checks to only enforce local requirements match the exact global
requirements for the py3.5 and later entries.
Python 2 requirements can still be present in the local files, but this
allows teams that want to remove all Python 2 code to clean up their
requirements files for entries that are no longer relevant.
Change-Id: Ifaa44593b08630f84bb50060871412c66315adcc
Signed-off-by: Sean McGinnis <sean.mcginnis@gmail.com>
This makes the output from checking requirements a little more verbose
when issues are found to help make it more obvious what the issue is
when there is a failure.
Change-Id: I85e3dc9525893de6be3fac4c952272bfb3474255
Signed-off-by: Sean McGinnis <sean.mcginnis@gmail.com>
Error message when package not found in the global requirements has
formatting placeholder for the missing package name, but no formatting
was being called to actually populate the name.
Change-Id: Ibf778c61f170fcb798dc93c79c9ab4cdae658c84
Signed-off-by: Sean McGinnis <sean.mcginnis@gmail.com>
Update blacklist, pbr and hacking are now in openstack organization
after the big OpenDev migration.
Change-Id: I094a589da1a2f56164ee32791d79db7bf6d0a768
This is a mechanically generated change to replace openstack.org
git:// URLs with https:// equivalents.
This is in aid of a planned future move of the git hosting
infrastructure to a self-hosted instance of gitea (https://gitea.io),
which does not support the git wire protocol at this stage.
This update should result in no functional change.
For more information see the thread at
http://lists.openstack.org/pipermail/openstack-discuss/2019-March/003825.html
Change-Id: I53162497c2f53e45139e6a3aa9ff20538ec1b35e
When handling an error, we were trying to combine data from the output
of multiple commands, some of which had already been converted to
strings (from bytes) and some of which had not. This is forbidden in
Python 3. (We were also trying to decode UTF-8 multiple times as a
result.)
Store all of the output as bytes, and decode if and when it is needed.
Change-Id: I35cd872f7bb38be1006bd6bf8dc910a1b52aadeb
XStatic-jQuery v1.12.4.1 it the latest version supported by Horizon and
plugins. Newer versions break Horizon gates.
Related-Bug: #1794028
Story: https://storyboard.openstack.org/#!/story/2003856
Change-Id: Ia3671c695bffce22af94115315cab3c943aefc2f
The idea behind the version-map code is to work around a lack of a node
that has multiple python3 versions by taking a freeze from one version
(say python-3.5) and cloning that to another (say python-3,4). This was
written to facilitate the transition from trusty (3.4) to xenial (3.5).
With the transition from xenial (3.5) to bionic (3.6) we need to do
something similar. To aid the transition it'd be nice to be able to
duplicate a 3.5 freeze to both 3.4 *and* 3.6. The current version_map
doesn't allow for that.
Enhance the version_map code to accommodate this situation. The idea
would be to backport this as far as Ocata[1]
[1] We need to look again at separating the requirements code from the
data
Change-Id: I8784509bc162eb6f2e80261bc2d81dbe63ce7989
Takashi Kajinami