On Tue, Mar 12, 2013 at 11:22:21AM -0300, Lucas Meneghel Rodrigues wrote:
>>>provisioning/inventorying mechanisms provided by beaker
for various labs.
>>These patches look like a great start. There are some coding style
>>inadequacies, that will need to be addressed, mainly:
>Thanks. I have to modify them to the new beaker API, but my most
>important piece is the bootstrapping hack.
>If that is a no-go, then I have to come up with another solution first.
Sure. Having some harnesses to have a bootstrap stage is fine. If
anything, bootstrap methods could be implemented in the other
harnesses as no-ops, just for the sake of uniformity.
So we may proceeed with this idea. In fact, I like the fact it is
simple and doesn't require a daemon running.
Yes, so do I. I am not a fan of daemons for this.
>>1) Fix usage of CamelCase. The only exception are class names.
>My python-foo is so limited, I don't know what CamelCase is. :-(
CamelCase is naming classes and methods with a mixture of
uppercase/lowercase characters. In autotest, it is fine for class
names, but not for methods, attributes and other general variable
names. For those, all_lowercase_with_underscores is recommended.
>>2) Docstring format
def foo(param1, param2):
Long description of method foo.
@param param1: A thing called param1 that is used for a bunch of stuff
that has methods bar() and baz() which raise SpamError if
something goes awry.
@return a list of integers describing changes in a source tree
>>3) Use of old style classes
Also something simple. Instead of doing
Shouldn't affect the outcome (although I've seen cases where it
brings a quirk or two) and makes usage of super() safer.
>More things I don't know what they are. :-(
>>There are other small issues, mostly related to PEP8 here and there.
>>That all said, I'm going patch by patch checking the general goals,
>>and running some static checking to shake up small bugs.
>And PEP8 is also another new thing for me. :-(
PEP8 is a sort of base reference for python coding style.
The autotest code style inherits from it, and the differences are
outlined in the coding style document:
Ah. Thanks that makes sense.
I offer to pick up your patches, fix all those inadequacies and
small bugs, then have a branch ready from where you can pull and
resume work from there. Does that sound good to you?
You are too kind. Considering I have to rewrite the beaker backend to
conform to the new API, I am not sure it is worth it right now. Perhaps
after that update we can start that?