fix and test for issue 1365: exception subclasses should not be recog… #1372
Conversation
…nized as fabric commands
| @@ -125,6 +126,7 @@ def is_classic_task(tup): | |||
| callable(func) | |||
| and (func not in _internals) | |||
| and not name.startswith('_') | |||
| and not (inspect.isclass(func) and issubclass(func, Exception)) | |||
There was a problem hiding this comment.
I'm wondering to myself if it makes sense that any class is a task? I'm wondering if maybe we should just refuse classes. Suppose I want to generate some csv from a bunch of servers and I put the following in my file: from csv import CsvWriter, Dialect -- with current master, fabric will list Dialect Describe an Excel dialect. in fab -l.
There was a problem hiding this comment.
I think what you say is totally reasonable, and would be all for excluding all classes and not just exception subclasses.
FWIW, I made this change for exceptions only because it seemed like a good combination of useful/safe. It's useful because, for quick fabfiles, I'm betting exceptions are imported more often than classes. It's safe because even though there's probably one maniac out there that has some crazy work flow that depends on the existing fabfile behaviour with respect to classes, surely no one is counting on the existing Exception behaviour, right?
There was a problem hiding this comment.
Fair enough, I do agree that some crazy person could be using __init__ as a task and I agree this seems less likely to break for anyone.
There was a problem hiding this comment.
Class-based tasks are actually a definite (if minority) use case, so the limitation of "it's an Exception" should stay, IMHO.
|
Dropping #1365 here for linkage. |
|
Cherry-picked to 1.10 branch as 4e1fd83 - closing & releasing soon, thanks! |
…nized as fabric commands