These functions are needed for T79.
Edit: Also change bodhi_utils functions to class methods, so that we don't create BodhiClient instance on import.
Details
New tests added.
Diff Detail
- Lint
Lint Skipped - Unit
Unit Tests Skipped
Other than the bunch import in test_bodhi_utils, looks pretty good to me.
I am wondering if we should import rpmUtils from dnf instead of yum, though since yum should be going away before too long
| testing/test_bodhi_utils.py | ||
|---|---|---|
| 9 | Bunch isn't from fedora.client. This dep would be better expressed explicitly and imported as from bunch import Bunch | |
I am wondering if we should import rpmUtils from dnf instead of yum, though since yum should be going away before too long
I checked YUM's rpmUtils and DNF's rpmUtils and there are some differences, it seems it has been rewritten a bit. But the parts we use are the same. So let's be progressive and use the DNF version.
I added a dependency on python-fedora and dnf. We will need to make it optional in future in order to have Taskotron distro-independent (therefore importing DNF only when operating in 'Fedora' mode).
| testing/test_bodhi_utils.py | ||
|---|---|---|
| 9 | Good catch, thanks. That reminded me that we didn't have python-fedora in requirements.txt. Added. | |
| testing/test_bodhi_utils.py | ||
|---|---|---|
| 9 | Should not be bunch in requirements.txt then? I know it is a dependency of python-fedora, just not sure what the consensus is here, since the import is not "from" python-fedora, but from bunch directly. | |
| testing/test_bodhi_utils.py | ||
|---|---|---|
| 9 | Yeah, I agree. If we import from bunch directly, we should add it to requirements.txt. | |
Agreed that bunch should be added to requirements.txt but other than that, it looks good.
One further change. I talked to Aleš Kozumplík from DNF and he said they are going to get rid of rpmUtils very soon. He recommended me to use hawkey for NVR format parsing. So, that's good news, instead of dnf we can rely on cross-distribution hawkey.
But, here's the catch. In past, we worked with ENVRA when needed (1:foo-1.2-3.fc20.x86_64). Current hawkey implementation supports only NEVRA parsing (foo-1:1.2-3.fc20.x86_64). Aleš told me that YUM used to output in ENVRA format, but DNF uses NEVRA format, and that NEVRA is "the more correct one". I checked and DNF really outputs NEVRA. So, those checks and library pieces that need to work with an epoch, they'll need to operate on NEVRA (unless we want to write our own convertor). I think that shouldn't be much of a problem, so I adjusted the current code, but we will see what the future holds. Koji and Bodhi communicate with NVR only, so there shouldn't be any problem. With ResultsDB it might be a bit more difficult, we will see about that.
New patch attached.
But, here's the catch. In past, we worked with ENVRA when needed (1:foo-1.2-3.fc20.x86_64). Current hawkey implementation supports only NEVRA parsing (foo-1:1.2-3.fc20.x86_64)
Do koji and bodhi support NEVRA? Where else were we using ENVRA and could this cause problems elsewhere?
Do koji and bodhi support NEVRA? Where else were we using ENVRA and could this cause problems elsewhere?
They do and they don't. From what I've tried, you can see epoch in getBuild() method in Koji, but you must query and operate on packages using NVR only. If you add epoch (ENVR or NEVR) to the query, it doesn't work. It's the same with Bodhi. So with these services we want to communicate with NVR only.
I searched in AutoQA sources and it seems that upgradepath was the most notable user of epoch. I'll handle that. Other than that, I haven't found anything else worth mentioning.
We will probably need to discuss things in relation to ResultsDB (whether to store the results with build NVR, ENVR or NEVR), but that's probably better dealt with in a different ticket. In any case, we can always create some ENVR<->NEVR converter. I just wanted to mention this issue, because at least for me this is an important difference between YUM defaults and DNF defaults. But I don't see any immediate problems, otherwise I wouldn't have adjusted the code without much hesitation.
But I don't see any immediate problems, otherwise I wouldn't have adjusted the code without much hesitation
Yeah, turns out that koji doesn't really understand epocs for searching, anyways. Searches should be done on the srpm's NVR and we don't query koji for any ENVRs. IIRC, we didn't for AutoQA, either.
Long story short, I agree that it isn't much risk at all
Overall, looks good to me.
The only thing missing is that the spec file needs to be updated with python-hawkey as Requires and BuildRequires
Bunch isn't from fedora.client. This dep would be better expressed explicitly and imported as from bunch import Bunch