Description of problem: Latest update of bodhi client from 2.8.1-1.fc27 -> 2.9.0-2.fc27 introduced a new python2 dependency. Quick grep did not show anything about hard dependency on pythn2-dnf. I know you might be very busy and do not have a time to port bodhi from python2 -> python3 but I would appreciate at least weak dependency on opional python2-dnf Version-Release number of selected component (if applicable): sh$ rpm -q bodhi-client-2.9.0-2.fc27.noarch bodhi-client-2.9.0-2.fc27.noarch How reproducible: Deterministic Steps to Reproduce: 1. rpm -q --requires bodhi-client | grep dnf Actual results: sh$ rpm -q --requires bodhi-client | grep dnf python2-dnf Expected results: Either python3-dnf or nothing Additional info: I was not able to find a way how to trigger this code from bodhi-client. sh$ grep -C6 dnf /usr/lib/python2.7/site-packages/bodhi/{__init__.py,client/*.py} /usr/bin/bodhi /usr/lib/python2.7/site-packages/bodhi/client/bindings.py- def testable(self): /usr/lib/python2.7/site-packages/bodhi/client/bindings.py- """ Get a list of installed testing updates. /usr/lib/python2.7/site-packages/bodhi/client/bindings.py- /usr/lib/python2.7/site-packages/bodhi/client/bindings.py- This method is a generate that yields packages that you currently /usr/lib/python2.7/site-packages/bodhi/client/bindings.py- have installed that you have yet to test and provide feedback for. /usr/lib/python2.7/site-packages/bodhi/client/bindings.py- /usr/lib/python2.7/site-packages/bodhi/client/bindings.py: Only works on systems with dnf. /usr/lib/python2.7/site-packages/bodhi/client/bindings.py- """ /usr/lib/python2.7/site-packages/bodhi/client/bindings.py: import dnf /usr/lib/python2.7/site-packages/bodhi/client/bindings.py: base = dnf.Base() /usr/lib/python2.7/site-packages/bodhi/client/bindings.py- sack = base.fill_sack(load_system_repo=True) /usr/lib/python2.7/site-packages/bodhi/client/bindings.py- query = sack.query() /usr/lib/python2.7/site-packages/bodhi/client/bindings.py- installed = query.installed() /usr/lib/python2.7/site-packages/bodhi/client/bindings.py- with open('/etc/fedora-release', 'r') as f: /usr/lib/python2.7/site-packages/bodhi/client/bindings.py- fedora = f.readlines()[0].split()[2] /usr/lib/python2.7/site-packages/bodhi/client/bindings.py- tag = 'f%s-updates-testing' % fedora sh$ grep testable /usr/lib/python2.7/site-packages/bodhi/{__init__.py,client/*.py} /usr/bin/bodhi /usr/lib/python2.7/site-packages/bodhi/client/bindings.py: def testable(self): It might be used in bodhi-server. But in such case it should be probably moved from bodhi-client to bodhi-server. But weak dependency is fastest and does not require any upstream changes :-) Thank you in advance.
dnf has always been a requirement for the python bindings (and not for server purposes), it was just never declared and it was imported incorrectly. Also, in 2.10.0 it becomes a hard requirement: https://github.com/fedora-infra/bodhi/blob/ea115dc0fa09c09532165bfbf31d206cb72ee5a3/bodhi/client/bindings.py#L40 I do intend to port Bodhi to Python 3, but at the current time I have dependencies that are still Python 2 only and am about to gain one large new Python 2 dependency (pungi).
(In reply to Randy Barlow from comment #1) > dnf has always been a requirement for the python bindings (and not for > server purposes), it was just never declared and it was imported > incorrectly. Also, in 2.10.0 it becomes a hard requirement: > I already mentioned that ticket description. You can see it in output of grep. Would you be so kind and could you explain how can I trigger code path which use dnf. Because I was not able to find where is method "testbable" used. So if There is not a way how to trigger that code patch from /usr/bin/bodhi then weak dependency make a sense.
The bodhi-client package is not only for /usr/bin/bodhi - it is also Bodhi's Python bindings. Though the code in question is not used by /usr/bin/bodhi, it is a formally documented and supported feature of the Python bindings, which are intended to be used by third party libraries. The bindings are also how the /usr/bin/bodhi client works in general (and some bits of the server use them too). Thus, this is a real dependency.
(In reply to Randy Barlow from comment #3) > The bodhi-client package is not only for /usr/bin/bodhi - it is also Bodhi's > Python bindings. Though the code in question is not used by /usr/bin/bodhi, > it is a formally documented and supported feature of the Python bindings, > which are intended to be used by third party libraries. The bindings are > also how the /usr/bin/bodhi client works in general (and some bits of the > server use them too). Thus, this is a real dependency. Even though I didn;t get direct answer to may question I infer that you confirmed that it is not possible to trigger that code path from /usr/bin/bodhi(bodhi-client) I understand that python bindings are not only for client and might be used also for other purposes. But main consumers of /usr/bin/bodhi are fedora package maintainers. Because it it more convenient to update package from command line then clicking in webUI. And I do not expect that pungi(+24 additional packages) will be used by package maintainers. This is a reason why title of this BZ is reduce dependencies for bodhi-client. There are more ways how to do it. (Use weak dependencies in python-bodhi, split python-bindigs into two packages, ...) That's decision for author.
This bug appears to have been reported against 'rawhide' during the Fedora 27 development cycle. Changing version to '27'.
bodhi-client 3.6.0 switched to python3. So dependency on python2-dnf is gone sh$ rpm -q --requires bodhi-client | grep dnf sh$ rpm -q --requires python3-bodhi | grep dnf sh$ rpm -q --requires python3-bodhi-client | grep dnf python3-dnf We can close this ticket
Indeed, and thanks for the comment - I had forgotten to associate this ticket with the build. Note that only Rawhide uses Python 3 even though Fedora 28 also has bodhi-3.6.0, since it was a backwards incompatible change and was done relatively late in the Fedora 28 cycle.
(In reply to Randy Barlow from comment #7) > Indeed, and thanks for the comment - I had forgotten to associate this > ticket with the build. Note that only Rawhide uses Python 3 even though > Fedora 28 also has bodhi-3.6.0, since it was a backwards incompatible change > and was done relatively late in the Fedora 28 cycle. That's fine I use rawhide :-)