I'm pleased to announce the latest version of Flask-Script. This introduces some major changes including: - decorators for creating script commands from functions (the Command class can still be used as before) - use of docstring rather than "description" for help text - application-scope options Documentation is here: http://packages.python.org/Flask-Script/ Source is here: http://bitbucket.org/danjac/flask-script (Please submit any tickets to the BitBucket repository.) Thanks again to the support and feedback of the pocoo community.
> I'm pleased to announce the latest version of Flask-Script. This > introduces some major changes including: > > - decorators for creating script commands from functions (the Command > class can still be used as before) > - use of docstring rather than "description" for help text > - application-scope options Nice, very flasky. I don't understand the need to pass app to commands, it's already in the module namespace unless we use the factory pattern in which case current_app should work as commands are run in a test context. Oh how I wish we had annotations in 2.x, would be useful for adding help descriptions to arguments. Maybe you could make a help decorator that writes __annotations__, future compatible! These would do the same: @manager.help(name='Your name') @manager.option('-n', '--name', help='Your name') Just a thought, not important. Docs say there's a @shell decorator, shouldn't that be @manager.shell? Picky as I am I'm going to complain that I don't like the prompt_bool name :) maybe something with "verify"? verify() prompt_[for_]verification() etc... It should also say "... [yN]" etc not just "[N]". Is the input case sensitive? Great work, I'm going to use this extension methinks. Thanks!
Thanks for the input ! On 22 July 2010 01:01, Dag Odenhall <dag.odenhall@gmail.com> wrote: >> I'm pleased to announce the latest version of Flask-Script. This >> introduces some major changes including: >> >> - decorators for creating script commands from functions (the Command >> class can still be used as before) >> - use of docstring rather than "description" for help text >> - application-scope options > > Nice, very flasky. > > I don't understand the need to pass app to commands, it's already in the > module namespace unless we use the factory pattern in which case > current_app should work as commands are run in a test context. > True. It could be because I don't really like current_app :-) It's a good point though, as the request context is enabled when the script is run, so current_app is available. Plus, many scripts don't actually need the app at all. I'd consider a removal in 0.3, but it would be a breaking change - something I'm not too keen on doing unless there are a) not too many people using Flask-Script or b) nobody objects. > Oh how I wish we had annotations in 2.x, would be useful for adding help > descriptions to arguments. Maybe you could make a help decorator that > writes __annotations__, future compatible! These would do the same: > > @manager.help(name='Your name') > @manager.option('-n', '--name', help='Your name') > I did very much consider @help, to work with the @command decorator. However the @option command already covers this, so it seemed a bit redundant. > Just a thought, not important. > > Docs say there's a @shell decorator, shouldn't that be @manager.shell? > Yes, will fix. > Picky as I am I'm going to complain that I don't like the prompt_bool > name :) maybe something with "verify"? verify() > prompt_[for_]verification() etc... It should also say "... [yN]" etc not > just "[N]". Is the input case sensitive? I suppose prompt_bool is clear - it converts the answer into a boolean - and consistent as you have prompt_choices etc. The defaults and choices are configurable (or at least are configurable in the latest repo), so you have a list of "yes" and "no" choices that are acceptable that you can change (for example, for different languages). Prompt_choices also needs a change, to allow for tuple options e.g. (1, "admin") instead of "admin". > > Great work, I'm going to use this extension methinks. Thanks! > >
I've created an app-removal branch which gets rid of the "app" first argument to all commands: http://bitbucket.org/danjac/flask-script/src/94ed5e3047e7 On 22 July 2010 08:12, Dan Jacob <danjac354@gmail.com> wrote: > Thanks for the input ! > > On 22 July 2010 01:01, Dag Odenhall <dag.odenhall@gmail.com> wrote: >>> I'm pleased to announce the latest version of Flask-Script. This >>> introduces some major changes including: >>> >>> - decorators for creating script commands from functions (the Command >>> class can still be used as before) >>> - use of docstring rather than "description" for help text >>> - application-scope options >> >> Nice, very flasky. >> >> I don't understand the need to pass app to commands, it's already in the >> module namespace unless we use the factory pattern in which case >> current_app should work as commands are run in a test context. >> > > True. It could be because I don't really like current_app :-) It's a > good point though, as the request context is enabled when the script > is run, so current_app is available. Plus, many scripts don't > actually need the app at all. > > I'd consider a removal in 0.3, but it would be a breaking change - > something I'm not too keen on doing unless there are a) not too many > people using Flask-Script or b) nobody objects. > >> Oh how I wish we had annotations in 2.x, would be useful for adding help >> descriptions to arguments. Maybe you could make a help decorator that >> writes __annotations__, future compatible! These would do the same: >> >> @manager.help(name='Your name') >> @manager.option('-n', '--name', help='Your name') >> > > I did very much consider @help, to work with the @command decorator. > However the @option command already covers this, so it seemed a bit > redundant. > >> Just a thought, not important. >> >> Docs say there's a @shell decorator, shouldn't that be @manager.shell? >> > > Yes, will fix. > >> Picky as I am I'm going to complain that I don't like the prompt_bool >> name :) maybe something with "verify"? verify() >> prompt_[for_]verification() etc... It should also say "... [yN]" etc not >> just "[N]". Is the input case sensitive? > > I suppose prompt_bool is clear - it converts the answer into a boolean > - and consistent as you have prompt_choices etc. The defaults and > choices are configurable (or at least are configurable in the latest > repo), so you have a list of "yes" and "no" choices that are > acceptable that you can change (for example, for different languages). > > Prompt_choices also needs a change, to allow for tuple options e.g. > (1, "admin") instead of "admin". > >> >> Great work, I'm going to use this extension methinks. Thanks! >> >> >
> I've created an app-removal branch which gets rid of the "app" first > argument to all commands: > > http://bitbucket.org/danjac/flask-script/src/94ed5e3047e7 Cool! I think it is more "flasky", as for example request is a context local in Flask.