Optimize rpm_to_build in koji utils by using multiCall
for simultaneous downloading of several builds.
Details
py.test -F testing/, run (patched) depcheck.
Diff Detail
- Repository
- rLTRN libtaskotron
- Lint
Lint Skipped - Unit
Unit Tests Skipped
Other than that, LGTM.
libtaskotron/koji_utils.py | ||
---|---|---|
37–38 | since this is not used anymore, please remove the line and the respective comment | |
37–38 | Add comment explaining that the buildinfos are returned in the same respective order as the rpms on input. | |
53 | Please explain in a comment why this (and the other similar) block of code is written like this. |
I think it's fine, but I'd really like to display Koji response in the error. Separating the sections for better readability is also preferred. Eliminating duplicate queries would be a nice bonus, but it depends on how simple you could write it. This ticket is about performance optimization, but we still don't want cryptic code. But I guess it could be written in a readable manner :)
libtaskotron/koji_utils.py | ||
---|---|---|
41–42 | If you want to be more precise here, you can use: :param rpms: ... :type rpms: list of str | |
44–45 | Just a note, I like to highlight param names which makes the descriptions simpler and clearer. So for example you can write it like ... in the same respective order as in ``rpms`` | |
63–75 | I understand the purpose here - check error codes and call further queries simultaneously. However, would it be more readable if you split this into two separate cycles? Like this: # check errors for rpminfo in rpminfos: if isinstance(rpminfo, dict): raise ... # request builds self.session.multicall = True for rpminfo in rpminfos: self.session.getBuild(rpminfo[0]['build_id']) buildinfos = self.session.multiCall() | |
67 | map->dict, if you edited this | |
72 | Can you please also specify which RPM caused the problem and the response from Koji (error code and string)? | |
73 | If you wanted to get really fancy, you could eliminate duplicate queries to the same build_ids. There will be probably a lot of them. You could make the list unique, and then match the results back to original list of RPMs. | |
81–82 | Again, let's show the Koji response. | |
testing/test_koji_utils.py | ||
77–87 | I guess this could be extracted into a separate method that would accept two input arguments, and the return them on the first and the second call? Then you would use this method from both test_* methods (and possibly some other methods in the future). |
Just a side note, I have tested it on 7 packages from f19-updates-testing and it took 1.4s, old method took 10.3s.
since this is not used anymore, please remove the line and the respective comment