extracting python module import/execution as a standalone directive. Fixes T76
ClosedPublic

Authored by tflink on Jan 24 2014, 6:40 PM.

Details

Summary

just moving code to import and execute python code to a separate directive, not fixing any of the other issues in the runner

Test Plan

added several unit tests, have tested on my local system to make sure that the example tasks still run.

Diff Detail

Branch
feature/T76-python-directive-refactor
Lint
No Linters Available
Unit
No Unit Test Coverage
ralph added a comment.Jan 24 2014, 7:09 PM

Generally, this is cool; +1!

I just have a couple pedantic complaints in the source above.

libtaskotron/directives/python_directive.py
13

Just a note on terminology. In python, a method is *always* part of a class. If it is not part of a class then it is a function.

Is there a particular reason why you are disallowing methods-on-a-class? Could a user do something like this in their task?

class MyClass(object):
    def my_task(self):
        return 42

my_hidden_object = MyClass()

i_want_taskotron_to_execute_this = my_hidden_object.my_task

taskotron (I think) doesn't necessarily need to know that i_want_taskotron_to_execute_this is *really* a method on an object, although it is.

Similarly, a task writer might provide something like this:

class MyTaskClass(object):
    def __call__(self):
        return 42

i_want_taskotron_to_execute_this = MyTaskClass()

Then, taskotron would try to call i_want_tasktron_to_execute_this and (I think) succeed.. even though that thing is neither a function nor a method. It is a *callable*.

I think that's the best choice of language for the PythonDirective docs. Something like

This code must be part of a valid python module and must be a valid callable.

libtaskotron/runner.py
64–65

There is no need to keep the .keys() call here. The default iterator for a dict just returns the keys.

88

This line seems excessively long. Perhaps break it out for readability?

options = {'basedir': basedir, 'method_name': 'run', 'workingdir': self.workdir}
exec_output = helper.process(pyfilename, options, {})

Thanks for the comments, will update to address concerns raised - especially around the function/method/callable stuff

libtaskotron/directives/python_directive.py
13

Thanks for the terminology correction. I was pretty sure that I was being inaccurate but wasn't quite sure what the right terminology was :)

The rationale was code simplicity and getting this done since folks are blocked for lack of examples. I didn't want to deal with conditionals on loading a class and then finding a method in that class right now. I wasn't planning on having the 'function only' restriction in the long term.

Now that I'm thinking about it, I'm not sure I see a whole lot of functional difference between what's written and what you're proposing. However, I prefer the way you're approaching it (referring to a callable instead of caring about function/method/class) - it's not really more complex and avoids the stated, but not-needed restriction on functions vs. methods.

libtaskotron/runner.py
88

Actually, the entirety of this logic is going away soon (I've already started that refactoring) as it's way too hard-coded but that's no excuse for poor quality code :)

tflink updated this revision.Jan 24 2014, 10:11 PM
  • changed funcional test names to functest for more differentiation and disabled running of functional tests by default
  • changed python directive around to work on callables instead of function names, cleaned up docs and added some tests
  • cleaned up some calls, not-needed calls to keys() and updated runner for changes in python directive
ralph accepted this revision.Jan 25 2014, 1:50 AM

I want to get some docs around this code written, so I changed the reviewers/ccs to get going to merge it since it has been reviewed. If anyone who hasn't seen the code yet has concerns about it, please let me know.

tflink closed this revision.Jan 26 2014, 12:18 AM