Prettify some of the code
ClosedPublic

Authored by jskladan on Jan 19 2016, 3:10 PM.

Details

Summary

Got rid of some of the passing around of instances of objects.

Test Plan

Try if the code still works as expected.

Diff Detail

Repository
rOPENQA fedora_openqa
Lint
Automatic diff as part of commit; lint not applicable.
Unit
Automatic diff as part of commit; unit tests not applicable.
jskladan retitled this revision from to Prettify some of the code.Jan 19 2016, 3:10 PM
jskladan updated this object.
jskladan edited the test plan for this revision. (Show Details)
jskladan added reviewers: garretraziel, adamwill.

So, um. OK. +1 to dropping the JSON parsing bits (I noted at the time I added the force stuff that this ought to be possible now). It does result in generating a couple of openQA API hits every half hour (or however often the 'current' timer runs), but that's not really a problem.

+1 to the ff_rel / build change, I think.

I'm +1 to 'officially' making the wikitcms dep mandatory - the intent at some point was for it to be optional so you can do everything but jobs_from_current and result reporting without it, but I don't think this matters much any more (and it's broken at present - in the last re-arrangement we had report import it unconditionally and cli imports report, so the try/except stuff for the import in cli is fairly pointless). If @garretraziel thinks otherwise, speak up :)

I don't really think do_report is any better than report ("report" is a verb, "I reported the results", so what's the point of 'verbifying' it?) but I don't really mind it if you insist. Ditto the uniqueres stuff, I don't mind, sure. I'm not really sure how much of an improvement it is to pass the wiki_url around instead of the instantiated wiki instance - it just leads to duplication of the wiki instantiation in jobs_from_current and report_results - but I don't hate it. +/-0 to all of those.

scheduler/fedora_openqa_schedule/report.py
168

I don't think you really need to jump through hoops to keep wiki_url optional. All the internal users pass wiki or wiki_url (with your changes) now, we don't have any external consumers of this stuff I don't think, and you're changing function signatures willy-nilly everywhere else anyway so we're already throwing compatibility out the window with this change.

So, just make it mandatory and ditch the if clause. And the sadface. :)

scheduler/fedora_openqa_schedule/schedule.py
217

I'm not really sure making this private is an improvement; OK, external consumers can use jobs_from_compose(), but if they happen to already be using fedfind and have a fedfind Release object, wouldn't it make sense to let them use this instead of having to turn it back into a release/milestone/compose for jobs_from_compose? And is renaming it really necessary?

I'm +1 to 'officially' making the wikitcms dep mandatory - the intent at some point was for it to be optional so you can do everything but jobs_from_current and result reporting without it, but I don't think this matters much any more (and it's broken at present - in the last re-arrangement we had report import it unconditionally and cli imports report, so the try/except stuff for the import in cli is fairly pointless). If @garretraziel thinks otherwise, speak up :)

I agree.

I'm not really sure how much of an improvement it is to pass the wiki_url around instead of the instantiated wiki instance - it just leads to duplication of the wiki instantiation in jobs_from_current and report_results - but I don't hate it. +/-0 to all of those.

I think that purpose is that if you want to use these functions for example from IPython, you probably don't want to import wikitcms (and look through documentation on how to instantiate its object) before you call that function. So you only pass normal Python objects around.

scheduler/fedora_openqa_schedule/report.py
168

I agree, change function signature and make wiki_url mandatory.

scheduler/fedora_openqa_schedule/schedule.py
217

I think that it's okay - I assume that whenever will somebody want to use scheduler.py as a module, he probably will not have fedfind object at hand. And still, you CAN use functions with undescore at the beginning, if you want.

garretraziel commandeered this revision.Jan 22 2016, 12:55 PM
garretraziel edited reviewers, added: jskladan; removed: garretraziel.
  • correcting some errors
jskladan commandeered this revision.Jan 22 2016, 12:57 PM
jskladan edited reviewers, added: garretraziel; removed: jskladan.
jskladan added inline comments.Jan 22 2016, 1:02 PM
scheduler/fedora_openqa_schedule/schedule.py
217

I don't really think that there are any "external customer" to begin with, but I see you point. On the other hand, I firmly believe in "internal closure" of libraries - meaning that externally available methods should not require an argument from external library. On top of that, marking the method with underscore does not make it private, you can still easily import it, it just means that it's not intended to be used from outside the library. Which IMHO is the fact here.

I'll rename i back to _jobs_from_fedfind though, as it probably makes more sense naming-vise.

jskladan updated this revision to Diff 1876.Jan 22 2016, 1:07 PM
  • Some renaming; made wiki_url required arg
garretraziel accepted this revision.Jan 22 2016, 1:11 PM

Looks OK, works.

This revision is now accepted and ready to land.Jan 22 2016, 1:11 PM
Closed by commit rOPENQAc53db64e6705: Prettify some of the code (authored by Josef Skladanka <jskladan@redhat.com>). · Explain WhyJan 22 2016, 1:32 PM
This revision was automatically updated to reflect the committed changes.

We don't have any external users at present, but we were explicitly writing with the possibility that there might be some in mind - for e.g. if we wanted to have scheduling done by taskotron.