A tiny correction: I did find a simple (but perhaps crude) way to make my decorators cooperate, which I just pushed.
(.. I simply created a `_needs_connect` helper which, before your `func_code` inspection, checks if there is a `_wrapped_command` attribute on the command and inspects that instead if present..) Best regards, Niklas On Tue, Oct 21, 2008 at 3:14 PM, Niklas Lindström <[EMAIL PROTECTED]> wrote: > Hi Christian and Jeff! > > I've continued my work and am ready to discuss it. Prior to that I > need to raise some issues though. I have pulled your recent changes > (which this thread is about), and come up with some problems. I raise > these in this mail but will post another one about my changes as well, > so we can discuss them more separately. > > > 1. Using `require` for the variable "fab_hosts" now has no effect, > since it is present as an empty list by default. It would work if > "fab_hosts" is removed from the default variables in ENV again.. What > do you think? > > > 2. This only affects my decorator utilities. The use of func_code > introspection to trigger _connect doesn't play with these. This is > since the func_code is from of the wrapper that calls e.g. `require`, > and not the actual command function. I have no *easy* way to fix > this, so for now the decorators aren't helpful for anything using > remote operations. :/ > > My options are either to back out my decorators, or to attempt to > change the analysis of which code needs `_connect` to be called. I > have some ideas, but perhaps you already have further plans for this > part? > > > Best regards, > Niklas > > > On Tue, Oct 21, 2008 at 2:02 PM, Christian Vest Hansen > <[EMAIL PROTECTED]> wrote: >> On Tue, Oct 21, 2008 at 6:10 AM, Jeff Forcier <[EMAIL PROTECTED]> wrote: >>> After a bunch of merging and cherry-picking (still learning Git, it >>> seems...), my master branch should now represent all the relevant >>> changes on Christian's side of things, as applied to what used to be >>> the execution branch. >> >> I got your pull request and have merged. I also made a couple of >> changes to polish it a bit and ease the transition from `rolling` and >> `fanout` fab_modes to `broad`, `deep`, `serial` and `parallel`. >> Otherwise, I discovered that fabfiles that explicitly set an >> unsupported fab_mode will experience some odd behaviour when run. >> >> -- >> Venlig hilsen / Kind regards, >> Christian Vest Hansen. >> >> >> _______________________________________________ >> Fab-user mailing list >> [email protected] >> http://lists.nongnu.org/mailman/listinfo/fab-user >> > _______________________________________________ Fab-user mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/fab-user
