fedpkg

#560 Various modernizations, including dropping use of python-fedora and support for bodhi-client < 6
Merged by onosek. Opened by adamwill.
adamwill/fedpkg drop-bodhi5  into  master

Download 560.patch

This PR is motivated by the desire to drop python-fedora usage as we want to get rid of that library, but there were various logical follow-ons from that. It is only currently used to handle an error that may be raised by version of bodhi-client before 6.0.0, but bodhi-client 6.0.0 is the oldest version that can possibly authenticate against production Bodhi any more, so there is not really any point supporting older bodhi-client any more.

Beyond that: we drop py36 from the tox envs, because that env only has bodhi-client 5.x so we can't really test against it any more. I did try not to actually remove any 3.6 compatibility, though, in case someone wants to try and make bodhi-client 6.x work with Python 3.6 for EL 8 (I don't particularly). We drop all use of six, because we don't need Python 2.x compat any more. We replace the deprecated use of linux_distribution to try and guess the appropriate runtime environment (disttag) with use of distro instead, which I verified exists back to EL 8. The new code should be somewhat better than the old but cannot cover all possibilities. We update the unittest imports to get rid of unittest2 usage and contingencies for unittest not existing, which were all only of use on Python 2.x or early 3.x. And we update the Bodhi version check in cli.py to check for >= 6.0.0. It will no longer smoothly handle the exception which is (apparently) raised if you somehow contrive to have < 2.0, but I don't think we need to worry about that any more.

LGTM, but CI is unhappy:

==================================== ERRORS ====================================
____________________ ERROR collecting test/test_bugzilla.py ____________________
ImportError while importing test module '/src/test/test_bugzilla.py'.
Hint: make sure your test modules/packages have valid Python names.
Traceback:
/usr/lib64/python3.6/importlib/__init__.py:126: in import_module
    return _bootstrap._gcd_import(name[level:], package, level)
test/test_bugzilla.py:16: in <module>
    from fedpkg.bugzilla import BugzillaClient
fedpkg/__init__.py:21: in <module>
    from .bodhi_6 import BodhiClient, UPDATE_TYPES, REQUEST_TYPES, SUGGEST_TYPES
fedpkg/bodhi_6.py:13: in <module>
    from bodhi.client.constants import UPDATE_TYPES, REQUEST_TYPES, SUGGEST_TYPES  # noqa
E   ModuleNotFoundError: No module named 'bodhi.client.constants'
______________________ ERROR collecting test/test_cli.py _______________________
ImportError while importing test module '/src/test/test_cli.py'.
Hint: make sure your test modules/packages have valid Python names.
Traceback:
/usr/lib64/python3.6/importlib/__init__.py:126: in import_module
    return _bootstrap._gcd_import(name[level:], package, level)
test/test_cli.py:38: in <module>
    import fedpkg.cli
fedpkg/__init__.py:21: in <module>
    from .bodhi_6 import BodhiClient, UPDATE_TYPES, REQUEST_TYPES, SUGGEST_TYPES
fedpkg/bodhi_6.py:13: in <module>
    from bodhi.client.constants import UPDATE_TYPES, REQUEST_TYPES, SUGGEST_TYPES  # noqa
E   ModuleNotFoundError: No module named 'bodhi.client.constants'
____________________ ERROR collecting test/test_commands.py ____________________
ImportError while importing test module '/src/test/test_commands.py'.
Hint: make sure your test modules/packages have valid Python names.
Traceback:
/usr/lib64/python3.6/importlib/__init__.py:126: in import_module
    return _bootstrap._gcd_import(name[level:], package, level)
test/test_commands.py:16: in <module>
    from utils import CommandTestCase
test/utils.py:21: in <module>
    import fedpkg.cli
fedpkg/__init__.py:21: in <module>
    from .bodhi_6 import BodhiClient, UPDATE_TYPES, REQUEST_TYPES, SUGGEST_TYPES
fedpkg/bodhi_6.py:13: in <module>
    from bodhi.client.constants import UPDATE_TYPES, REQUEST_TYPES, SUGGEST_TYPES  # noqa
E   ModuleNotFoundError: No module named 'bodhi.client.constants'
_____________________ ERROR collecting test/test_utils.py ______________________
ImportError while importing test module '/src/test/test_utils.py'.
Hint: make sure your test modules/packages have valid Python names.
Traceback:
/usr/lib64/python3.6/importlib/__init__.py:126: in import_module
    return _bootstrap._gcd_import(name[level:], package, level)
test/test_utils.py:20: in <module>
    from fedpkg import utils
fedpkg/__init__.py:21: in <module>
    from .bodhi_6 import BodhiClient, UPDATE_TYPES, REQUEST_TYPES, SUGGEST_TYPES
fedpkg/bodhi_6.py:13: in <module>
    from bodhi.client.constants import UPDATE_TYPES, REQUEST_TYPES, SUGGEST_TYPES  # noqa
E   ModuleNotFoundError: No module named 'bodhi.client.constants'
=============================== warnings summary ===============================
../tmp/tox/py36/lib/python3.6/site-packages/rpm.py:15
  /tmp/tox/py36/lib/python3.6/site-packages/rpm.py:15: UserWarning: The RPM Python bindings are not currently available via PyPI.
  Please install them with your distro package manager (typically called
  'python2-rpm' or 'python3-rpm'), and ensure that any virtual environments
  needing the API are configured to be able to see the system site packages
  directory.
    warnings.warn(warning_msg)

Oh, right, we need to also drop 3.6 from the CI config. Will get to that in a bit. The errors are just the symptom of the latest bodhi-client available on 3.6 in pypi being a pre-6.x version.
Edited by adamwill

rebased onto a270fc793e483135cb346fba97335a6e994d7dac

rebased onto a270fc793e483135cb346fba97335a6e994d7dac

not sure why CI is still running 'py36' (but it's python 3.12) but not running py313. There's really no py36 anywhere in the code any more.

not sure why CI is still running 'py36' (but it's python 3.12) but not running py313. There's really no py36 anywhere in the code any more.

I was keeping py36 CI because Python 3.6 was a default for EPEL 8 and fedpkg is still built for this release. Do you also think that producing that build is not needed anymore? Maybe deactivating failing tests for 3.6 (by decorating) would be possible too? To have at least limited fedpkg's functionality while Bodhi functionality is not available in this release.
Edited by onosek

Sure, it's possible. Hard to find the motivation to do it, though. It should only be as broken as before with this PR, I just turned off the tests...I can maybe look at it if you really think it's needed.

This should probably be:

if distro.id() == 'rhel' or 'rhel' in distro.like().split():

@adamwill: No problem, I can merge (after checking) the first 5 commits of yours and modify the last one to achieve that.

This should probably be:

if distro.id() == 'rhel' or 'rhel' in distro.like().split():

oh, yeah, that sounds nice. I'll change it.

6 new commits added

  • Update check_bodhi_version to check for >= 6.0.0
  • Modernize and clean unittest imports
  • Replace and update use of deprecated 'linux_distribution'
  • Drop all usage of six
  • Drop support for bodhi-client <= 5
  • tox.ini, Jenkinsfile: drop py36, add py313

Updated with Carl's suggestion.

Commit 565bdcbc fixes this pull-request

Pull-Request has been merged by onosek

OK, I finally finished the review and I made few changes:

commit #1: I didn't drop py36, because I still want to build fedpkg for EPEL8 though with limited functionality without the Bodhi.

commit #2: I enclosed import from .bodhi_6 to catch an exception on EPEL 8.

commit #4: test/test_commands.py - test_return_for_el
I had to patch distro.like() as well, because for 'centos' and 'almalinux', the second part of the condition matches. It was failing on all versions.

if distro.id() == 'rhel' or 'rhel' in distro.like().split():

CI: https://jenkins-fedora-infra.apps.ocp.cloud.ci.centos.org/job/fedpkg-pipeline/277/

Thanks a lot, @adamwill for such a big chunk of code.

oh, right, I forgot to update the test when changing the conditional. thanks.
Metadata
None
No Tags
Static archive. pagure.io was sunset in 2026; this is a read-only snapshot.
Red Hat Logo

Fedora is sponsored by Red Hat. Learn more about the relationship between Red Hat and Fedora »

© Red Hat, Inc. and others.