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

[Christian Vest Hansen]

Hi, Niklas.

On Sat, Oct 18, 2008 at 8:30 PM, Niklas Lindström <address@hidden> wrote:
> Hi!
>
> Here's my follow-up about implementation of my suggestions. The patch
> I attach is from my first proper use of Git, so please forgive and
> correct me if I've botched this-or-that. And do scrutinize my code.

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.

Although, I'm not sure what to do instead.

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

>
> I don't know if Christian or Jeff wants to merge this right away (and
> change stuff you dislike). I will of course do any fixes you require
> prior to an eventual merge if you don't approve of my design.
>
>
> == Included in the patch ==
>
> * improved "prompt":
>
>    - new keyword "retry". If True, will re-prompt until value is not None.
>
>    - validate can be a regexp *string*. It will be compiled into a regexp
>      whose "match" method will be called with the given value (unless it's
>      None).
>
>    - new keyword "auto". If used, prompt will *not* prompt if the value of
>      "auto" is not None. It will still validate though (and thus re-prompt if
>      "retry" is True).
>
>      *Note*: maybe this should be merged with the existing mechanism of not
>      prompting if the var is already "set"? By replacing auto with that, but
>      reasonably still validate the actual value.
>
> * improved "require":
>    - can take more than one varname and require *all* of them to be provided.
>
>
> That's all.
>
> I do have some things I'd like to get to work on rather soon. These are:
>
>
> == 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 :(

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

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

>
>
> == 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.

> * Provide a mechanism for directory scoped file system operations.
>
>
> Would you like me to take a stab at these?

Sure, go ahead. And feel free to ask if you have any questions.

>
> Best regards,
> Niklas
>
> _______________________________________________
> Fab-user mailing list
> address@hidden
> http://lists.nongnu.org/mailman/listinfo/fab-user
>
>



-- 
Venlig hilsen / Kind regards,
Christian Vest Hansen.