Jorge Vargas wrote: > 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.
In paster all of sys.argv after the command name is passed on. Is that a problem? I use Command.standard_parser() in Paste to keep the arguments consistent. You might want a tg.Command.standard_parser() that to that the typical options that TG uses. I'm personally leaning towards using setup.py for internal code maintenance commands. But if anything distutils is considerably more crude in how it parses the command line. > 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. Why do you need these three-level commands? If you want, you could create a subclass of paster's Command class that does more dispatching. You could even just look for an entry point of "%s %s" % (self.name, self.args[0]), same entry point type as Paster's current commands (since it's basically the same interface). > 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. I suppose you could, though there's no completion. You'd have to get the classes and instantiate them yourself, and then catch SystemExit when the commands are run. Maybe just invoke "command -h" when you hit tab twice or something. >>> 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. I'm not sure how long it's been there; maybe it wasn't there when you first started. There's also some methods for editing files, like command.insert_into_file( os.path.join(output_dir, 'setup.py'), 'Extra requirements', 'some text', indent=True) You can use this in your template's post() method. Paste deploy uses it: http://svn.pythonpaste.org/Paste/Deploy/trunk/paste/deploy/paster_templates.py You have to have '-*- Extra requirements -*-' in your source file, to indicate where the text would go. It's not great, but it'll get the work done when there's a lot of contention over a single file (like setup.py). -- 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 -~----------~----~----~----~------~----~------~--~---
