agronholm / agronholm/apscheduler

APScheduler 4.0 progress tracking

Open
#465 206 comments 129 reactions 0 assignees View on GitHub
Dominant language
Python
Stars
7.6k
Forks
783
Avg merge
4d 8h
Merged PRs (30d)
5

Description

I'm opening this issue as an easy way to interested parties to track development progress of the next major APScheduler release (v4.0).

## Terminology changes in v4.0

The old term of "Job", as it was, is gone, replaced by the following concepts which are closer to the terminology used by Celery:

- Task definition: a uniquely named callable coupled with configuration like maximum number of instances, misfire grace time etc.
- Schedule: binds a trigger with a task definition
- Job: queued work item for an executor (binds to a task definition, and optionally a schedule)

Also, the term "executor" is now being changed to "worker".

Notice that the terminology may still change before the final release!

## Planned major changes

v4.0 is a ground-up redesign that aims to fix all the long-standing flaws found in APScheduler over the years.

Checked boxes are changes that have already been implemented.

- [X] Async-first design, with support for asyncio and trio (via [AnyIO](https://github.com/agronholm/anyio))
- [X] Static typing friendly ([PEP 561](https://www.python.org/dev/peps/pep-0561/))
- [X] Support for serializers other than pickle
- [X] Broader time zone support, including zoneinfo time zones ([PEP 615](https://www.python.org/dev/peps/pep-0615/))
- [X] Drop support for Python < 3.7
- [X] [Calendar interval trigger](https://github.com/agronholm/apscheduler/blob/master/apscheduler/triggers/calendarinterval.py)
- [X] Stateful triggers
- [X] `threshold` value for `AndTrigger` (resolves issues with contained `IntervalTrigger` instances)
- [X] The interval trigger should start right away and not after the first interval (#375)
- [X] Persistent store sharing among multiple schedulers (arguably the most needed feature ever for APScheduler)
- [X] Decoupling of schedulers and workers
- [x] Schedule-level jitter support
- [x] Context-local job metadata information
- [x] Easy launching of tasks immediately without needing a schedule
- [x] Failure resilience for persistent data stores (so they don't crash the scheduler on a temporary outage)

Potential extra features I would like to have:

- [ ] Support for tags in task definitions, schedules and jobs (#798)
- [ ] Stateful jobs
- [ ] Ability to cancel jobs
- [ ] Timeouts for jobs
- [ ] "threshold" value for `OrTrigger` (#453)

You will notice that I have dropped a number of features from master. Some I may never add back to v4.0, even if requested, but do voice your wishes in this issue (and this issue **only** – I will summarily close such requests in new tickets). Others have been removed only temporarily to give me space for the redesign.

## Features on the chopping block

- Twisted scheduler (may be usable through the async scheduler if AnyIO ever gets Twisted support)
- Tornado scheduler (just use the async scheduler)
- Gevent scheduler (does not play well with the new architecture)
- ~Qt scheduler (difficult to test/maintain)~
- Redis as a data store (may not have sophisticated enough querying capabilities)
- Rethink data store (the company has gone belly up some time ago)
- Zookeeper as a data store (may not have sophisticated enough querying capabilities)

Being on the chopping block does not mean the feature will be gone forever! It may return in subsequent minor release or even before the 4.0 final release if I deem it feasible to implement on top of the new architecture.

Contributor guide

Open the contributing guide

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.