David Smith wrote: >>> I've attached patches to pastescript and pastedeploy to support >>> what I had in mind: a pastedeploy abstract factory for commands >>> that receive the standard config and then do anything they want >>> and a simple entry_point supporting runner command for >>> paster. See the test case in pastedeploy and after patching >>> paste you can run with a command such as >>> >>> $ paster cmd -n batch basic_app.ini >> One way I considered doing this is simply something like: >> >> paster fetch config.ini /batch >> >> Which would fetch whatever was at /batch -- this seems simpler. On IRC >> Ben and I talked some about using this general technique to also replace >> setup-app (this was after a bunch of issues in Pylons where context >> wasn't set up in the setup and test cases the same way as in actual >> operation). > > This is a good idea but I don't think it satisfies the same > need well. The more I think about it, it leaves the usage and > construction of bundled scripts even stranger. That is, paste > would expcect whatever runs at that URL to be conformant to > WSGI, but > > # writing a batch script as a WSGI callable is backwards. It > should be a standard python script (possibly with a factory > function) that only imports things from paste, not use > tricks to make it look like a regular, non-WSGI callable. > > # mounting the command in the webapp's URL tree is needlessly > complex. The author (or some wrapper) would have to check > the value of the environ variable you suggest to determine > if it was a web request or a console request.
There's some complexity here, though, because config files can be fairly complex, and the frontend object isn't necessarily the "application". E.g.: [filter-app:main] use = egg:Paste#evalerror next = real_app [app:real_app] use = egg:MyApp ... The main application isn't an application at all, it's just a middleware wrapper around the real application. And potentially the application constructor does arbitrary stuff with the configuration before actually instantiating the components. There's also a minor redundancy, because the "use = egg:MyApp" determines what the handler is, while a script would likely predetermine the package and would be redundant with that information. This stuff started coming up with the Pylons setup-app and test framework, where we've incrementally added better config setup and wrapping, but it's still just ad hoc and will likely break if you have any more complex setups. URLs make much more sense to me, because they fit into the stack in a very natural way. Certainly it's not entirely natural to squeeze a command-line program into a request invocation, but I think it's the best compromise. PylonsController is probably not the right framework for implementing the controller, but writing the framework for a command shouldn't be that hard IMHO. The framework is going to handle checking the special key for security, parsing the command line arguments and potentially providing a optparse-like interface (or creating a set of arguments that can be fed directly into optparse). Also, some of the wrappers provide real benefits for the command-line program, like the exception handler. At least for cron scripts, having good per-script email reports of errors is really nice (I abhor how cron normally handles errors). In the context of Pylons, I think Pylons could set up a separate path specifically for this, probably in a different directory than controllers/. I think it's reasonable to consider isolating end users from the paster command, and providing a more constrained interface than just passing in an arbitrary path. But that's largely a separate issue -- mostly one of providing an easy-to-setup wrapper around all the paster commands. -- Ian Bicking | [EMAIL PROTECTED] | http://blog.ianbicking.org _______________________________________________ Paste-users mailing list [email protected] http://webwareforpython.org/cgi-bin/mailman/listinfo/paste-users
