On 7/2/07, Ian Bicking <[EMAIL PROTECTED]> wrote: > > Jorge Vargas 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. > > I'm not sure what the distinction between paster and a real CLI is? The > structure in paster is there to make it easier to write high-quality > command line scripts in a pluggable fashion. > sorry now that I read this i mix up two ideas.
1- TG cli sucks it's basically a ton of classes all parsing sys.argv with their own switches and no consistent documentation. in order to create a new command you need to create a class and figure out which part of sys.argv is going to be send to you and then parse that. which is what we'll end up if it gets reimplemented on top of paster because that's how paster works. 2- paster, paste script to be exact is way too complicated for "normal" tg commands, paster is build on top of optparse which at least in TG case will maintain the huge set of switches, most TG commands could be ran with a simpler structure of "tg2-admin cmd subcommand" this is due to some things being set by default like the project, model,etc. Second the fact that paster commands are classes goes against how TG-cli is implemented which is sets of commads, (please correct me if I'm wrong here) the only way I see we can implement sets of commands on pastescript is to have one class implement the command and in it's run method parse to get the "subcommand" part which makes it esencially imposible to add new subcommands to already existing commands. what I'm proposing is a discoverable API instead of a declarative API, instead of having a usage string use the docstring, instead of having flags use positional params, top that with readline support and an interactive shell and you have a help of a cmd tool. I think this idea got to me from trac-admin and svn client, for example they have commads like "trac-admin permission list" and "svn help status", I don't see how this can be implemented on top of pastescript. > > 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. > > Can you just have multiple templates, like turbogears_sqlobject and > turbogears_sqlalchemy? They can both depend on a base turbogears > template, and just add their specific items. > > You can also raise paste.script.copydir.SkipTemplate in a template to > skip a file completely. The function skip_template(condition) that is > available by default allows you to do this. You can use this to provide > full files that are skipped or included based on something. E.g., > skip_template(model!='SQLAlchemy') in a SQLAlchemy-based file. ohh that's interesting, it seems that when we did the code to support SA/SO we didn't saw that, current branching code is handle inside the cheetah template with #if, and ugly conditionals. I'll take a look at that to see if we can provide a better way to build up the project templates. > > > -- > Ian Bicking | [EMAIL PROTECTED] | http://blog.ianbicking.org > | Write code, do good | http://topp.openplans.org/careers > > > > --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
