On Mon, Oct 20, 2008 at 5:05 PM, Niklas Lindström <[EMAIL PROTECTED]> wrote: > Hi Christian! > > I've addressed some things in my new branch (fork..) which I've cloned > from github, but I'm afraid I still feel somewhat uncomfortable with > git. :( > > I'm not sure whether to work on my own master branch, nor if I should > create a branch in my repo in which to pull in your public master.. > Right now I've added changes to master in my fork, and then > fetched+merged the change to markdown docstrings (using git remote to > manually track your repo). This has been pushed to my github repo.
I'm not that experienced in working with repos that are forks, but I put stuff in my master branch that I intend to push at some point and I create local branches for everything else. When I integrated parts of your patch, I created a new local branch and, while perusing the diff, selectively applied the parts I liked. Then I fiddled the bytes a little until I was satisfied and merged it into my master for pushing. That process won't be much different with 3'rd party remote branches. > > > Here's what I've continued with: > > On Sun, Oct 19, 2008 at 4:18 AM, Christian Vest Hansen > <[EMAIL PROTECTED]> wrote: >> I've accepted your changes to require() but I'm not sure about the >> prompt() changes. I think prompt is getting a little complex/hard to >> understand. Also, it'd be nice if you had updated the doc-string. > > Great; I'm glad that you found the changed require() useful. > >> Although, I'm not sure what to do instead. > > I understand your concerns with what I did with prompt(). I'm after > three things: > > 1. To (always) repeat the prompt if validate fails. I skipped the > 'repeat' flag in my new version. > > 2. To invoke a given validate even if we have a supplied value. I just > removed my 'auto' keyword and changed the use of a present varname in > ENV so that this gets validated as well.. > > 3. I'd like to use regexp validations, so I've kept the overloaded > 'validate' (and updated the docstring) which uses the RegexpValidator > (previously named Matcher). Do you think allowing regexp strings is a > bad idea? Perhaps we could keep RegexpValidator or similar, so at > least that one is available as a convenience tool? Though think I'd > prefer a less "obtrusive" helper.. These three points make It _sound_ better. I don't know if Jeff has put any code towards any of his ideas regarding prompt, though I don't see anything in the commit log for his master branch. > > >>> (I haven't used the git-mechanism for mailing patches, just >>> generation. If I'm going to continue like this, perhaps I should also >>> set up my branch on git-hub, as Jeff has?) >> >> A github branch is a good idea. Cherry-picking, merging and viewing >> changes online is easy, and the commit message and author is >> preserved. > > Working on doing this properly. :) > > >>> == To do next == >>> >>> * add unittests for the above (I've only "acceptance"-tested the above >>> in my actual fabfiles). >> >> Ah, yes. The unit testing story is a little weak. I'm afraid I've been >> sloppe in that department :( > > I'll see if I can add a suite of all commands. Personally I really > like Nose (<http://pypi.python.org/pypi/nose>) for driving tests. Do > you have any preferences in this department? I don't have any preferences. Not even for the feeble attempt already in the code base. > > >>> * improved "load": >>> - will only invoke the loaded fab script once. Thus multi-file based fab >>> setups can shared loaded scipts without having them invoked multiple >>> times. >>> >>> * new operation "call_once": >>> - will call the given function (command) *unless* it has already been >>> called. >> >> These ideas I like. Especially the improvements to load. > > I have *preliminary* working versions of these. Especially call_once > needs more thinking though (regarding messages, and if we could reuse > the '_execute_commands' logic for parameters etc -- see my TODO > scribble). You can use pull-request (github feature) or send an email when you think it's ready. > > >>> * new decorators >>> >>> @requires >>> Calls "require" with the given args before invoking the decorated >>> command. >>> >>> @depends >>> Calls "call_once" with the given args before calling the decorated >>> command. >> >> These would be the first decorators intended for use in fabfiles. >> You/we will have to think about how they are going to interoperate >> with the list and help commands. > > Absolutely. I've added these, without any documentation, and will > continue with how to register them and integrating that in the help > system. '@depends' will also be aligned with how I'll proceed with > improving 'call_once'. Sounds good :) > > >>> == After that == >>> >>> * replace current "set" and "get" with a more powerful "params" object. >> >> They're called variables in fabric terminology. I wonder what you have >> in mind here. > > Basically I just like to (as Jeff also seemed to) solve the issue that > 'set' currently shadows the builtin with the same name. We then toyed > with the idea of exposing one object to replace the get/set (which I > fully understand if you don't want to remove though for e.g. > compatability, clean names etc). Since 'vars' is also a builtin, I > thought of 'params'. Perhaps e.g. 'var' would be better.. Working > something like: > > # Define one or more variables (just as with current "set"): > var(fab_user='me') > var(fab_hosts=[...], fab_user='me') > > # Define one var can also be done like: > var.fab_user = 'me' > var['fab_user'] = 'me' > > # For getting them, same pattern: > print var.fab_user > print var['fab_user'] Looks nice. I think `var` is a good name. I wasn't totally happy with the shadowing when I introduced `set` but I couldn't come up with a better name. It's OK to break a little backwards compatibility when the version series changes from 0.0.x to 0.1.x. > > ---- > > Unless I'm working backwards, I hope my use of git and github will be > of help for you in tracking my suggestions. Please ask me to fix > documentation and complete/reimplement what I have working now, in > case you'll eventually like to merge more of it. > > Best regards, > Niklas > -- Venlig hilsen / Kind regards, Christian Vest Hansen.
_______________________________________________ Fab-user mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/fab-user
