Re: [Fab-user] Patch for prompt and require

[Niklas Lindström]

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.


Here's what I've continued with:

On Sun, Oct 19, 2008 at 4:18 AM, Christian Vest Hansen
<address@hidden> 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..


>> (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?


>> * 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).


>> * 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'.


>> == 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']

----

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