Hey Erich, On Fri, Jul 15, 2011 at 8:47 AM, Erich Heine <[email protected]> wrote: > I would propose a "task protocol" like so: > 1. @task wraps a function in a task object (if it is not already such an > object) > 2. Any decorator that assumes a task wraps the function in a task object, if > it is not already such an object. > 3. Any decorator that doesn't assume a task (but is officially part of > fabric) must have semantics that can work with a task object or explicitly > fails because it doesn't handle task objects.
I don't have time right now to go over the meat of your proposal, but I do want to highlight that Travis and I were previously discussing "normalizing" the system so that even classic-style tasks become wrapped in Task objects. So the above protocol of sorts would fit right into this idea, and I agree that it would be a good way to limit/fix the decorator-ordering problem. Not sure we could slot it in immediately, though; I want to avoid running off on a(n even) long(er) "beef up the new Task stuff" tangent -- there's other changes (parallel, logging etc) which take priority. But it definitely feels like a good thing to tackle in the medium-term future. Best, Jeff -- Jeff Forcier Unix sysadmin; Python/Ruby engineer http://bitprophet.org _______________________________________________ Fab-user mailing list [email protected] https://lists.nongnu.org/mailman/listinfo/fab-user
