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:
# comment self._rpm_to_build_cache = {}or
self._rpm_to_build_cache = {} ''' a docstring '''