[Buildbot-devel] Easy question

[Tom Prince]

On Tue, 31 Jan 2012 09:30:36 -0800, "Dustin J. Mitchell" <dustin at v.igoro.us> wrote:
> 2012/1/31 Benoît Allard <benoit at aeteurope.nl>:
> > Keeping an eye on backward compatibility, could you elaborate on the
> > above ? We might have a winner there !
> 
> We don't want to break existing custom steps or configs.  We can't use
> any Python magic, because this is about the simplest kind of magic,
> and it's causing confusion.  So either configs will need to change (we
> could go back to the old f.addStep(classname, (arguments,..)) format),
> or class implementations will need to change (so every custom class
> becomes two classes - a step factory and a step).
> 
> I think the best way forward up with a new, well-documented way to
> write buildsteps that *does* involve two classes, and just let the old
> way of doing so (with factory and step in the same class) die out of
> its own accord.

One posibility would be to seperate the function that checks the
arguments for sanity, seprate from the one that initializes the
object. (Which I guess is the primary reason for moving away from the
old method of specifying arguments?

So, something like

class BuildStep(object):
      def __init__(self, **kwargs):
          """for backwards compatability"""
          self.checkStepArgs(**kwargs)
          self.setFactoryArgs(**kwargs)
      
      @classmethod   ## Should this be a class method, or not
      def buildStep(class, **kwargs):
          """initialize object from kwargs"""
          self = class.__new__()
          self.kwargs = kwargs

      @classmethod
      def checkStepArgs(class, **kwargs):
          """Verify args make sense"""
         if condition:
            raise config.ConfigErrors([]) 
            
Probably more thought is required to allow mixing of old and new style
steps to coexist.

  Tom