[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Fab-user] Patch for prompt and require
From: |
Christian Vest Hansen |
Subject: |
Re: [Fab-user] Patch for prompt and require |
Date: |
Sun, 19 Oct 2008 04:18:01 +0200 |
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.