8000 Refactor JobQueue · Issue #1936 · python-telegram-bot/python-telegram-bot · GitHub
[go: up one dir, main page]
Skip to content
8000

Refactor JobQueue #1936

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Closed
Bibo-Joshi opened this issue May 2, 2020 · 3 comments · Fixed by #1981 or #1982
Closed

Refactor JobQueue #1936

Bibo-Joshi opened this issue May 2, 2020 · 3 comments · Fixed by #1981 or #1982

Comments

@Bibo-Joshi
Copy link
Member

Is your feature request related to a problem? Please describe.

Maintaining JobQueue is not easy and sometimes error prone, see e.g. #1338

Describe the solution you'd like

We could refactor JobQueue to use a third party library for the scheduling, keeping the run_* methods as wrappers. We should probably also add a run_cron as suggested in #1337 as convenience wrapper for all the other cases we can't all cover (like run a job every time mars and saturn align …)

Describe alternatives you've considered

Just implement run_cron would be a first step.
@Bibo-Joshi Bibo-Joshi added this to the 13.0 milestone May 2, 2020
@Bibo-Joshi
Copy link
Member Author
Bibo-Joshi commented May 24, 2020 •
edited
Loading

I did a bit looking around and to me it seems that we basically have 3 options here:

  • Pythons sched
    Advantages: standard lib, so well maintained and reliable
    Disadvantages: Only has very basic functionality, e.g. no recurring events. So we'd still have to do much of the work ourselfes

  • Third party schedule
    Advantages:

    • Easy to use internally, and externally, i.e. if a user wants a very specific job pattern they could do e.g. job_queue.every().wednesday.at("13:15").do(job)
    • Lightweight
    • around since 2013

    Disatvantages:

    • Tested only with py 2.7, 3.5, 3.6
    • Not veriy actively maintained (current version is 0.6.0, last commit 08/2019)
    • No native support for different timezones

  • Third party APScheduler
    Advantages:

    • extensive functionality (comes with a cron interface, several persistence options (in memory/with databases), has a Asyncio scheduler, …)
    • can handle timezones
    • tested with py 3.4-3.7 (but supports 3.6-3.8?!)
    • around since 2009

    Disatvantages:

    • THB I don't see any

If we're okay with adding a third party lib for the scheduling, i'd vote for APS, from my first impression.

@KellyHwong
Copy link
KellyHwong commented May 25, 2020 •
edited
Loading

If we're okay with adding a third party lib for the scheduling, i'd vote for APS, from my first impression.

I vote APScheduler. Clearly APScheduler's API is more readable.

This was referenced Jun 5, 2020
Merged
Closed
Closed
Closed
Closed
@Bibo-Joshi Bibo-Joshi removed this from the 13.0 milestone Jun 11, 2020
@Bibo-Joshi Bibo-Joshi mentioned this issue Jul 13, 2020
Merged
@Bibo-Joshi
Copy link
Member Author

#1981 has been merged into v13, so I'll close this

@github-actions github-actions bot locked as resolved and limited conversation to collaborators Aug 17, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
2 participants
@KellyHwong @Bibo-Joshi
0