On 7/2/07, Jorge Vargas <[EMAIL PROTECTED]> wrote: > Hi I just notice two things that got imported into trunk and I had to > post something. > > tg-admin and quickstart templates where the two of the most horrible > parts of the original TG. > > tg-admin grew out of the templates engine and that's why it's based on > paster and not a real commandline util. I say we need to stop that, > which brings us to the question does tg really needs a cmd tool? I > think we do but not for the core most of the old command module where > development tools and/or wrappers to other commandline tools, we need > to separate paster from the CLI and do a real CLI maybe based on the > cmd module and/or have commands be loaded from entry points but the > whole idea is too keep it simple none of this CLI tools are going to > be used by "mortal users" so they should be smart and try not to have > 100 switches noone will use. > > seconds the templates, they are horrible to code, all the branching > with SO/SA made me go dizzy, so we need a better approach to building > templates, and the problem is really with all the branching, for > example having a full project be build with optional > SO/SA/identitySO/identitySA, will mean having 4 different templates so > we really need second the size just look at > http://trac.turbogears.org/browser/trunk/tg/pastetemplates/turbogears/%2Bpackage%2B > that's almost 10 folders of stuff, stuff that is going to break > projects on updates, stuff people are never going to touch because > they may break something, do we really need ALL that stuff?? code > generation is sometimes the way to go but I'm starting to think here > it's a bad idea. specially with all those instances with the name of > the package, it makes it a pain to upgrade when the templates from > which you started changes. > > Don't you think we are imposing something way to rigid? > I started thinking about the cmd model and I wrote a small mockup. the general idea is that each tg set of related command is an entry point, pretty much like the old system. but now they must be modules (we could work around it to be classes too but I don't want that, see below).
So each function inside each module must be atomic, in the sense that it doesn't needs preprocessing like calling an __init__ or something. now if a function needs another function then first thing it should do is call it. And the key ingredient which is what I like about this model, all functions from all modules (even the ones plugged in from external packages) are available in the same way from the same place. The implementation is a bit hackish right now but the idea is to have command.module.function, now none of those call will fail because a thirdparty that demands a <module> should list it as a dependency on it's setup.py. take a look at this happening in commandrunner.commands.shell I think the most important feature of this model is that making new commands is trivial so trivial that you will probably end up writing several cmds that will help you develop your own particular project, and we'll have several 100s of commands. last but not least all modules should define at minimum two functions default and help, default is call when no subcommand is ask, and help on any error. to test it out. $untar, python setup.py develop $tg2 $tg2 info $tg2 shell $tg2 so create --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "TurboGears Trunk" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/turbogears-trunk?hl=en -~----------~----~----~----~------~----~------~--~---
commandRunner.tar.gz
Description: GNU Zip compressed data
