@@ -17,7 +17,7 @@ import codecs
import logging
import subprocess
from datetime import datetime, timedelta
-from pkg_resources import parse_version
+from packaging_legacy.version import parse as parse_version
import utils
import operator
import re
@@ -19,7 +19,7 @@ import re
import tempfile
import shutil
import errno
-from pkg_resources import parse_version
+from packaging_legacy.version import parse as parse_version
import itertools
import utils
import recipeparse
@@ -11,7 +11,7 @@ import sys
import re
from datetime import datetime
from itertools import islice
-from pkg_resources import parse_version
+from packaging_legacy.version import parse as parse_version
import reversion
from django import forms
@@ -24,6 +24,7 @@ gitdb==4.0.11
GitPython==3.1.41
kombu==5.3.4
mysqlclient==2.2.1
+packaging_legacy==23.0.post0
Pillow==10.2.0
prompt-toolkit==3.0.43
python-dateutil==2.8.2
@@ -16,7 +16,7 @@ import os
import optparse
import logging
import re
-from pkg_resources import parse_version
+from packaging_legacy.version import parse as parse_version
import git
from datetime import datetime
import calendar
Since we are only using parse_version for comparison (typically checking that we are greater than some minimum version for tool or package), one would think we can use packaging.version.parse as if it was parse_version Unfortunately, this requires conforming to PEP-440 version definitions, which does not work for e.g. autotools (2.72d) nor older openssl (1.1.1p). We rely in these (and to be sure other) cases on the LegacyVersion behavior. https://packaging.python.org/en/latest/specifications/version-specifiers/#summary-of-differences-from-pkg-resources-parse-version "This specification purposely restricts the syntax which constitutes a valid version while pkg_resources.parse_version attempts to provide some meaning from any arbitrary string." In order to have the least impact to the overall code, we instead add packaging_legacy to requirements.txt and use packaging_legacy.version.parse as if it was parse_version. https://pypi.org/project/packaging-legacy/ https://github.com/pypa/packaging/pull/407 Since pypi.org itself is depending on packaging_legacy (in fact, a pypi dev developed the package), we can expect it to be supported for quite some time. https://github.com/pypi/warehouse/pull/13500 [YOCTO #15348] Signed-off-by: Tim Orling <tim.orling@konsulko.com> --- Changes in v2: * Add packaging_legacy to requirements.txt * Use packaging_legacy instead of packaging since we rely on LegacyVersion behavior which has been removed * Fix a typo of "from packaging.version import parse_version" in layerindex/update_layer.py layerindex/update.py | 2 +- layerindex/update_layer.py | 2 +- layerindex/views.py | 2 +- requirements.txt | 1 + rrs/tools/upgrade_history_internal.py | 2 +- 5 files changed, 5 insertions(+), 4 deletions(-)