This method is required for depcheck's squashing of per-rpm results
to per-update results.
It takes a rpm filename on input and returns build info from koji.
It has "caching/prefetching" capabilities to speed-up subsequent queries.
Details
- Reviewers
kparal tflink - Maniphest Tasks
- T195: report depcheck results per update
- Commits
- rLTRNb420fe644aea: Add rpm_to_build() method to koji_utils
Tested with Depcheck several times
Diff Detail
- Repository
- rLTRN libtaskotron
- Lint
Lint Skipped - Unit
Unit Tests Skipped
I'd like to see some unit test coverage for the new method but the concept seems sound.
Too late, already pushed. But here are my comments.
libtaskotron/koji_utils.py | ||
---|---|---|
36 | Please document what this is for and how does it look inside. It's very unpleasant if one has to find that out from reading the code scattered around. Either use: # comment self._rpm_to_build_cache = {} or self._rpm_to_build_cache = {} ''' a docstring ''' | |
38 | I understand the reasoning behind prefetch, but I'm a bit concerned whether it is helpful enough. RPM searches in Koji take a long time. If there are several dozens of builds to run through depcheck, it will take a really long time, no matter buildinfo caching. I think this should rather take a list of rpm filenames as an input, and then make all the queries at once using Koji's multiCall. I imagine this will be at least 10x faster for larger sets of RPMs. You can have a look at upgradepath and see how multicall is used. I don't say it has to be implemented right now, but I think it would be highly preferable. If you decide to stay with current implementation because of time constraints, please at least file a ticket? | |
41 | Use need to use double backticks, if you're trying to highlight the text as code/value. | |
45 | Return type is documented, but return value is not. Let's say something like: :return: Koji buildinfo dictionary (as returned e.g. from :meth:`koji.getBuild`) | |
45 | :rtype: :class:`bunch.Bunch` | |
46 | I was a bit confused by the phrase "or build", because I don't specify "build" anywhere. Let's use "or its build", "or its related build" or something along the lines. | |
48 | Something like # strip path would help a bit for those of us who don't know the whole Python library by heart ;) |
libtaskotron/koji_utils.py | ||
---|---|---|
36 | Ooint taken, although I do not really see the need to document its contents as this is to be used only in the one piece of code, and the variable is marked as "private". But I guess there will be no harm in it. | |
38 | I can file the ticket, although from what I tried, this helps quite a lot. | |
41 | thx | |
46 | Thx, I'll be your SPHINX padawan soon enough :) | |
48 | *shrugs* OK, I can comment on that line, although # grab filename from path says more about the intent, I guess |
Please document what this is for and how does it look inside. It's very unpleasant if one has to find that out from reading the code scattered around. Either use:
or