Using system utilities like cron, can be suboptimal if all you're trying to do is schedule periodic tasks within an application, e.g. database cleanup tasks, periodic polling of other services etc.
The main gripes with cron are:
- cron can be overkill. It requires maintaining a separate crontab file for your app. Wit schedule you can keep everything in pure Python.
- cron is per machine. Multiple app servers require locks of some sort to prevent job duplication. To solve this, we could put triggered jobs on a shared jobqueue (beanstalkc, resque, ...) and have them processed by several workers.
- cron's syntax, while powerful, can be difficult to understand and maintain. Schedule provides an easy to read syntax based on the builder pattern, e.g. "schedule.every(2).hours.do(job, args)"
I wrote schedule because I needed a lightweight scheduling solution for a Python web service backend. It's 'clockwork' (https://github.com/tomykaira/clockwork) for Python.
The main gripes with cron are:
- cron can be overkill. It requires maintaining a separate crontab file for your app. Wit schedule you can keep everything in pure Python.
- cron is per machine. Multiple app servers require locks of some sort to prevent job duplication. To solve this, we could put triggered jobs on a shared jobqueue (beanstalkc, resque, ...) and have them processed by several workers.
- cron's syntax, while powerful, can be difficult to understand and maintain. Schedule provides an easy to read syntax based on the builder pattern, e.g. "schedule.every(2).hours.do(job, args)"
Much of this was said in better words by Addam Wiggins: http://adam.heroku.com/past/2010/4/13/rethinking_cron/
I wrote schedule because I needed a lightweight scheduling solution for a Python web service backend. It's 'clockwork' (https://github.com/tomykaira/clockwork) for Python.