If you intend to experiment with different implementations, then I think moving it to a branch is a good idea.
I have looked through some of the code but not all of it, nor have I had an oppotunity to actually try out your changes. I generally don't merge large'ish changes until I've tried them out in my own environment. Those are the reasons I have not yet made much of a response to your changes. The unit testing stuff is something that I'm looking forward to :) On Thu, Oct 23, 2008 at 2:28 PM, Niklas Lindström <[EMAIL PROTECTED]> wrote: > Hi again! > > I have reworked the implementation of this feature (and the @depends > which use this via `invoke`). It now plays correctly with Jeff's new > "executions" algorithm. This is in part because the decorators I added > no longer creates wrapped commands, but adds a call chain which is > invoked prior to the command. This also makes it explicit in the > output when commands are chained (i.e. triggered from other commands). > (And it isolates this feature better in the `_execute_command`.) > > Since as said this is a complex change, I am willing to move *all* > related code to a branch (including my decorators who add things to > this "call chain"), and use my master only for the more "conventional" > changes I hope you'll eventually accept (as per my other > "Change"-mails). > > (That way I can also experiment with alternative solutions to my > current use of @depends if you're not happy with how it works now.) > > (Furthermore I can also move forward with an upcoming change I'd like > to do to make Fabric "resettable", which would make my plans for > unittests of it all much easier. This'll build on my #2 (the "managed > namspace" change) and #3 (`DEFAULT_ENV` + `Configuration`). I'll get > back to this.) > > Best regards, > Niklas > > > > On Wed, Oct 22, 2008 at 12:14 AM, Niklas Lindström <[EMAIL PROTECTED]> wrote: >> [These changes are present in my fork of Fabric at >> <http://github.com/niklasl/fabric/tree/master>] >> >> >> == 7. Skipping executed commands == >> >> Added the `invoke` operator for prevention of multiple calls of commands. >> >> This is a somewhat invasive change, but I hope I've addressed it >> better now. Here's how it works now: >> >> My initial version only invokes a command once (unless you call it >> manually in code) at all times. Christian had a concern that this may >> play ill with at least the `set` command. I thus realized that it >> works very bad with commands that take arguments altogether. >> >> Therefore, now anything supplied on the command line is executed even >> if repeated. But *all* `_execute_command` invokations, including >> these, are remembered, *including* their arguments (see `_args_hash`). >> This is currently only used via `invoke`, which will not invoke the >> same command+args twice. >> >> (The only, in my opinion minor, "danger" is if `prompt` is used to >> possibly change a similar invocation after the command call. Since >> skips are also printed, even then the user will be notified of the >> skip.) >> >> Note: I won't object much if you find this too complex. I can then >> perhaps revert to a `call_once` (and associated `depends`) without >> support for arguments at all.. (Although I think it would be nice if >> it cooperated with the normal _execute_command.) >> >> >> ------------------------------------------ >> Best regards, >> Niklas >> > > > _______________________________________________ > Fab-user mailing list > [email protected] > http://lists.nongnu.org/mailman/listinfo/fab-user > -- Venlig hilsen / Kind regards, Christian Vest Hansen.
_______________________________________________ Fab-user mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/fab-user
