I got this to work and wrote a Cookbook article about it. http://wiki.pylonshq.com/display/pylonscookbook/Cron+jobs+and+command-line+utilities
I think Pylons could do with a base class that does part of what "paster shell" does, for use by command-line utilities. I'm looking into what kind of class would be useful. --Mike On Nov 7, 2007 4:10 PM, Mike Orr <[EMAIL PROTECTED]> wrote: > We've often discussed but never resolved where to put standalone > scripts and cron jobs related to a Pylons project. These might be for > database maintenance, data import/export, ad hoc scripts you might use > again someday, etc. Pylons apps don't have a 'bin' directory or > executable; everything is hung off 'paster' (or possibly a 'pylons' > command at some time in the future). This seems to leave two > possibilities: > > 1) Scripts registered in setup.py for the global 'bin' directory. A > standard package for these would be good, perhaps myapp.util, > myapp.scripts, myapp.standalone, or something like that. > > 2) Paster plugins. Apparently you can add a Paster command with an > entry point like: > > [paste.paster_command] > mycommand = package.module:Class > > However, I'm not sure how Paster would know which egg to look for > "paster mycommand" in, unless the current directory is the > application. Putting these globally in Paster when they're really > application-specific is also undesirable. > > Also, most of my utilities require a database connection which implies > an .ini file. This makes them *like* "paster setup-app" both in their > command-line syntax, need for an .ini file, and code for reading the > configuration (a la websetup.py). Sometimes you also need additional > command-line arguments or options. > > So, which way is better, and has anybody tried making an app-specific > Paster plugin? I guess we'll need a HOWTO on both strategies. I'm > concerned that it's so complicated to make standalone scripts for > Pylons apps that people just work around it, or at least I do, but > that's a disadvantage for Pylons. it's something that really should > be straightforward and easy and documented. > > Another issue is I don't really want all my application-specific > scripts in the global 'bin' directory: this means I have to name them > with a common prefix, etc. It almost seems worthwhile to have an > application supercommand that dispatches to each command module. But > that's what 'paster' is, a supercommand. > So maybe a "paster myapp mycommand myargs" would be worthwhile, where > 'myapp' means to look for a command in that package. Does this sound > like something feasable for Pylons? > > -- > Mike Orr <[EMAIL PROTECTED]> > -- Mike Orr <[EMAIL PROTECTED]> --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "pylons-discuss" 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/pylons-discuss?hl=en -~----------~----~----~----~------~----~------~--~---
