Mike Orr 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.
Similar to a script, in Python 2.5 you can do: python -m package.script And it'll be equivalent to: python path/to/package/script.py In Python 2.4 this only works for top-level modules. > 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. There's a different entry point for global commands. OTOH, to use the local command you either have to use paster --require=Package mycommand, or run paster mycommand from inside the source directory (it looks for some .egg-info directory in any parent directory of the pwd). I don't think this is great for deployed applications, though. > 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. This has kind of been hanging for a long time. I think I'm going to add a command: paster request config.ini / Which will run a request for / against the application described in config.ini. And then, maybe allow the ini file to have something like: [command_urls] /foobar = description of what / does /foobar alias = foobar Then you could do: paster request config.ini -h # get a list of urls in [urls] paster request config.ini foobar # from the alias Though... that's not ideal. Cloning that [urls] section everywhere is a pain. Maybe instead it should have a default URL of /.command-line/, and "paster request config.ini -h" calls /.command-line/?-h, and "paster request config.ini foobar" calls /.command-line/foobar. There would be a special key set to mark command-line access vs. web access, so you could restrict access appropriately. This has been a hanging issue for a long time, so it's really something I should just implement. To be "nice" in Pylons it would also require a Controller subclass that was customized to this kind of usage. -- Ian Bicking : [EMAIL PROTECTED] : http://blog.ianbicking.org --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
