Django APScheduler
==================
[](https://pypi.org/project/django-apscheduler/)
[](https://pypi.org/project/django-apscheduler/)
[](https://pypi.org/project/django-apscheduler/)
[](https://github.com/jcass77/django-apscheduler/actions?query=workflow%3A%22Python+package%22)
[](https://codecov.io/gh/jcass77/django-apscheduler)
[](https://pypi.org/project/black)
[APScheduler](https://github.com/agronholm/apscheduler) for [Django](https://github.com/django/django).
This is a Django app that adds a lightweight wrapper around APScheduler. It enables storing persistent jobs in the
database using Django's ORM.
django-apscheduler is a great choice for quickly and easily adding basic scheduling features to your Django applications
with minimal dependencies and very little additional configuration. The ideal use case probably involves running a
handful of tasks on a fixed execution schedule.
**PLEASE NOTE:** the trade-off of this simplicity is that you need to **be careful to ensure that you have only ONE
scheduler actively running at a particular point in time**.
This limitation is due to the fact that APScheduler does not currently have
any [interprocess synchronization and signalling scheme](https://apscheduler.readthedocs.io/en/latest/faq.html#how-do-i-share-a-single-job-store-among-one-or-more-worker-processes)
that would enable the scheduler to be notified when a job has been added, modified, or removed from a job store (in
other words, different schedulers won't be able to tell if a job has already been run by another scheduler, and changing
a job's scheduled run time directly in the database does nothing unless you also restart the scheduler).
Depending on how you are currently doing your
Django [deployments](https://docs.djangoproject.com/en/dev/howto/deployment/#deploying-django), working with this
limitation might require a bit of thought. It is quite common to start up many webserver worker process in production
environments in order to scale and handle large volumes of user traffic. If each of these worker processes end up
running their own scheduler then this can result in jobs being missed or executed multiple times, as well as duplicate
entries being created in the `DjangoJobExecution` table.
Support for sharing a persistent job store between multiple schedulers appears to be planned for
an [upcoming APScheduler 4.0 release](https://github.com/agronholm/apscheduler/issues/465).
So for now your options are to either:
1. Use a custom Django management command to start a single scheduler in its own dedicated process (**recommended** -
see the `runapscheduler.py` example below); or
2. Implement your
own [remote processing](https://apscheduler.readthedocs.io/en/latest/faq.html#how-do-i-share-a-single-job-store-among-one-or-more-worker-processes)
logic to ensure that a single `DjangoJobStore` can be used by all of the webserver's worker processes in a
coordinated and synchronized way (might not be worth the extra effort and increased complexity for most use cases);
or
3. Select an alternative task processing library that *does* support inter-process communication using some sort of
shared message broker like Redis, RabbitMQ, Amazon SQS or the like (see:
https://djangopackages.org/grids/g/workers-queues-tasks/ for popular options).
Features
--------
- A custom [APScheduler job store](https://apscheduler.readthedocs.io/en/latest/extending.html#custom-job-stores)
(`DjangoJobStore`) that persists scheduled jobs to the Django database. You can view the scheduled jobs and monitor
the job execution directly via the Django admin interface:
- The job store also maintains a history of all job executions of the currently scheduled jobs, along with status codes
and exceptions (if any):
**Note:** APScheduler
will [automatically remove jobs](https://apscheduler.readthedocs.io/en/latest/userguide.html#removing-jobs)
from the job store as soon as their last scheduled execution has been triggered. This will also delete the
corresponding job execution entries from the database (i.e. job execution logs are only maintained for 'active'
jobs.):
- Job executions can also be triggered manually via the `DjangoJob` admin page:
**Note:** In order to prevent long running jobs from causing the Django HTTP request to time out, the combined maximum
run time for all APScheduler jobs that are started via the Django admin site is 25 seconds. This timeout value can be
configured via the `APSCHEDULER_RUN_NOW_TIMEOUT` setting.
Installation
------------
```python
pip install django-apscheduler
```
Quick start
-----------
- Add ``django_apscheduler`` to your ``INSTALLED_APPS`` setting like this:
```python
INSTALLED_APPS = (
# ...
"django_apscheduler",
)
```
- django-apscheduler comes with sensible configuration defaults out of the box. The defaults can be overridden by adding
the following settings to your Django `settings.py` file:
```python
# Format string for displaying run time timestamps in the Django admin site. The default
# just adds seconds to the standard Django format, which is useful for displaying the timestamps
# for jobs that are scheduled to run on intervals of less than one minute.
#
# See https://docs.djangoproject.com/en/dev/ref/settings/#datetime-format for format string
# syntax details.
APSCHEDULER_DATETIME_FORMAT = "N j, Y, f:s a"
# Maximum run time allowed for jobs that are triggered manually via the Django admin site, which
# prevents admin site HTTP requests from timing out.
#
# Longer running jobs should probably be handed over to a background task processing library
# that supports multiple background worker processes instead (e.g. Dramatiq, Celery, Django-RQ,
# etc. See: https://djangopackages.org/grids/g/workers-queues-tasks/ for popular options).
APSCHEDULER_RUN_NOW_TIMEOUT = 25 # Seconds
```
- Run `python manage.py migrate` to create the django_apscheduler models.
- Add a [custom Django management command](https://docs.djangoproject.com/en/dev/howto/custom-management-commands/) to your project
that schedules the APScheduler jobs and starts the scheduler:
```python
# runapscheduler.py
import logging
from django.conf import settings
from apscheduler.schedulers.blocking import BlockingScheduler
from apscheduler.triggers.cron import CronTrigger
from django.core.management.base import BaseCommand
from django_apscheduler.jobstores import DjangoJobStore
from django_apscheduler.models import DjangoJobExecution
from django_apscheduler import util
logger = logging.getLogger(__name__)
def my_job():
# Your job processing logic here...
pass
# The `close_old_connections` decorator ensures that database connections, that have become
# unusable or are obsolete, are closed before and after your job has run. You should use it
# to wrap any jobs that you schedule that access the Django database in any way.
@util.close_old_connections
def delete_old_job_executions(max_age=604_800):
"""
This job deletes APScheduler job execution entries older than `max_age` from the database.
It helps to prevent the database from filling up with old historical records that are no
longer useful.
:param max_age: The maximum length of time to retain historical job execution records.
Defaults to 7 days.
"""
DjangoJobExecution.objects.delete_old_job_executions(max_age)
class Command(BaseCommand):
help = "Runs APScheduler."
def handle(self, *args, **options):
scheduler = BlockingScheduler(timezone=settings.TIME_ZONE)
scheduler.add_jobstore(DjangoJobStore(), "default")
scheduler.add_job(
my_job,
trigger=CronTrigger(second="*/10"), # Every 10 seconds
id="my_job", # The `id` assigned to each job MUST be unique
max_instances=1,
replace_existing=True,
)
logger.info("Added job 'my_job'.")
scheduler.add_job(
delete_old_job_executions,
trigger=CronTrigger(
day_of_week="mon", hour="00", minute="00"
), # Midnight on Monday, before start of the next work week.
id="delete_old_job_executions",
max_instances=1,
replace_existing=True,
)
logger.info(
"Added weekly job: 'delete_old_job_executions'."
)
try:
logger.info("Starting scheduler...")
scheduler.start()
except KeyboardInterrupt:
logger.info("Stopping scheduler...")
scheduler.shutdown()
logger.info("Scheduler shut down successfully!")
```
- The management command defined above should be invoked via `./manage.py runapscheduler` whenever the webserver serving
your Django application is started. The details of how and where this should be done is implementation specific, and
depends on which webserver you are using and how you are deploying your application to production. For most people
this should involve configuring a [supervisor](http://supervisord.org) process of sorts.
- Register any APScheduler jobs as you would normally. Note that if you haven't set `DjangoJobStore` as the `'default'`
job store, then you will need to include `jobstore='djangojobstore'` in your `scheduler.add_job()` calls.
Advanced usage
--------------
django-apscheduler assumes that you are already familiar with APScheduler and its proper use. If not, then please head
over to the project page and have a look through
the [APScheduler documentation](https://apscheduler.readthedocs.io/en/latest/index.html).
It is possible to make use
of [different types of schedulers](https://apscheduler.readthedocs.io/en/latest/userguide.html#choosing-the-right-scheduler-job-store-s-executor-s-and-trigger-s)
depending on your environment and use case. If you would prefer running a `BackgroundScheduler` instead of using a
`BlockingScheduler`, then you should be aware that using APScheduler with uWSGI requires some additional
[configuration steps](https://apscheduler.readthedocs.io/en/latest/faq.html#how-can-i-use-apscheduler-with-uwsgi) in
order to re-enable threading support.
Supported databases
-------------------
Please take note of the list of databases that
are [officially supported by Django](https://docs.djangoproject.com/en/dev/ref/databases/#databases). django-apscheduler
probably won't work with unsupported databases like Microsoft SQL Server, MongoDB, and the like.
Database connections and timeouts
---------------------------------
django-apscheduler is dependent on the standard Django
database [configuration settings](https://docs.djangoproject.com/en/dev/ref/databases/#general-notes). These settings,
in combination with how your database server has been configured, determine how connection management will be performed
for your specific deployment.
The `close_old_connections` decorator should be applied to APScheduler jobs that require database access. Doing so
ensures that Django's [CONN_MAX_AGE](https://docs.djangoproject.com/en/dev/ref/settings/#std:setting-CONN_MAX_AGE)
configuration setting is enforced before and after your job is run. This mirrors the standard Django functionality of
doing the same before and after handling each HTTP request.
If you still encounter any kind of 'lost database connection' errors then it probably means that:
- Your database connections timed out in the middle of executing a job. You should probably consider incorporating a
connection pooler as part of your deployment for more robust database connection management
(e.g. [pgbouncer](https://www.pgbouncer.org) for PostgreSQL, or the equivalent for other DB platforms).
- Your database server has crashed / been restarted.
Django [will not reconnect automatically](https://code.djangoproject.com/ticket/24810)
and you need to re-start django-apscheduler as well.
Common footguns
---------------
Unless you have a very specific set of requirements, and have intimate knowledge of the inner workings of APScheduler,
you really shouldn't be using `BackgroundScheduler`. Doing so can lead to all sorts of temptations like:
* **Firing up a scheduler inside of a Django view:** this will most likely cause more than one scheduler to run
concurrently and lead to jobs running multiple times (see the above introduction to this README for a more thorough
treatment of the subject).
* **Bootstrapping a scheduler somewhere else inside your Django application**: it feels like this should solve the
problem mentioned above and guarantee that only one scheduler is running. The downside is that you have just delegated
the management of all of your background task processing threads to whatever webserver you are using (Gunicorn, uWSGI,
etc.). The webserver will probably kill any long-running threads (your jobs) with extreme prejudice (thinking that
they are caused by misbehaving HTTP requests).
Relying on `BlockingScheduler` forces you to run APScheduler in its own dedicated process that is not handled or
monitored by the webserver. The example code provided in `runapscheduler.py` above is a good starting point.
Project resources
-----------------
- [Changelog](docs/changelog.md)
- [Release procedures](docs/releasing.md)
Raw data
{
"_id": null,
"home_page": "http://github.com/jcass77/django-apscheduler",
"name": "django-apscheduler",
"maintainer": "",
"docs_url": null,
"requires_python": "",
"maintainer_email": "",
"keywords": "django apscheduler django-apscheduler",
"author": "Jarek Glowacki, Stas Kaledin, John Cass",
"author_email": "jarekwg@gmail.com, staskaledin@gmail.com, john.cass77@gmail.com",
"download_url": "https://files.pythonhosted.org/packages/37/a2/3815e39c3ec7c83c721d9330380b2afad97b8fee9e83d19b23d4a47235f8/django-apscheduler-0.6.2.tar.gz",
"platform": "",
"description": "Django APScheduler\n==================\n\n[](https://pypi.org/project/django-apscheduler/)\n[](https://pypi.org/project/django-apscheduler/)\n[](https://pypi.org/project/django-apscheduler/)\n[](https://github.com/jcass77/django-apscheduler/actions?query=workflow%3A%22Python+package%22)\n[](https://codecov.io/gh/jcass77/django-apscheduler)\n[](https://pypi.org/project/black)\n\n[APScheduler](https://github.com/agronholm/apscheduler) for [Django](https://github.com/django/django).\n\nThis is a Django app that adds a lightweight wrapper around APScheduler. It enables storing persistent jobs in the\ndatabase using Django's ORM.\n\ndjango-apscheduler is a great choice for quickly and easily adding basic scheduling features to your Django applications\nwith minimal dependencies and very little additional configuration. The ideal use case probably involves running a\nhandful of tasks on a fixed execution schedule.\n\n**PLEASE NOTE:** the trade-off of this simplicity is that you need to **be careful to ensure that you have only ONE\nscheduler actively running at a particular point in time**.\n\nThis limitation is due to the fact that APScheduler does not currently have\nany [interprocess synchronization and signalling scheme](https://apscheduler.readthedocs.io/en/latest/faq.html#how-do-i-share-a-single-job-store-among-one-or-more-worker-processes)\nthat would enable the scheduler to be notified when a job has been added, modified, or removed from a job store (in\nother words, different schedulers won't be able to tell if a job has already been run by another scheduler, and changing\na job's scheduled run time directly in the database does nothing unless you also restart the scheduler).\n\nDepending on how you are currently doing your\nDjango [deployments](https://docs.djangoproject.com/en/dev/howto/deployment/#deploying-django), working with this\nlimitation might require a bit of thought. It is quite common to start up many webserver worker process in production\nenvironments in order to scale and handle large volumes of user traffic. If each of these worker processes end up\nrunning their own scheduler then this can result in jobs being missed or executed multiple times, as well as duplicate\nentries being created in the `DjangoJobExecution` table.\n\nSupport for sharing a persistent job store between multiple schedulers appears to be planned for\nan [upcoming APScheduler 4.0 release](https://github.com/agronholm/apscheduler/issues/465).\n\nSo for now your options are to either:\n\n1. Use a custom Django management command to start a single scheduler in its own dedicated process (**recommended** -\n see the `runapscheduler.py` example below); or\n\n2. Implement your\n own [remote processing](https://apscheduler.readthedocs.io/en/latest/faq.html#how-do-i-share-a-single-job-store-among-one-or-more-worker-processes)\n logic to ensure that a single `DjangoJobStore` can be used by all of the webserver's worker processes in a\n coordinated and synchronized way (might not be worth the extra effort and increased complexity for most use cases);\n or\n\n3. Select an alternative task processing library that *does* support inter-process communication using some sort of\n shared message broker like Redis, RabbitMQ, Amazon SQS or the like (see:\n https://djangopackages.org/grids/g/workers-queues-tasks/ for popular options).\n\nFeatures\n--------\n\n- A custom [APScheduler job store](https://apscheduler.readthedocs.io/en/latest/extending.html#custom-job-stores)\n (`DjangoJobStore`) that persists scheduled jobs to the Django database. You can view the scheduled jobs and monitor\n the job execution directly via the Django admin interface:\n\n \n\n- The job store also maintains a history of all job executions of the currently scheduled jobs, along with status codes\n and exceptions (if any):\n\n \n\n **Note:** APScheduler\n will [automatically remove jobs](https://apscheduler.readthedocs.io/en/latest/userguide.html#removing-jobs)\n from the job store as soon as their last scheduled execution has been triggered. This will also delete the\n corresponding job execution entries from the database (i.e. job execution logs are only maintained for 'active'\n jobs.):\n\n- Job executions can also be triggered manually via the `DjangoJob` admin page:\n\n \n\n **Note:** In order to prevent long running jobs from causing the Django HTTP request to time out, the combined maximum\n run time for all APScheduler jobs that are started via the Django admin site is 25 seconds. This timeout value can be\n configured via the `APSCHEDULER_RUN_NOW_TIMEOUT` setting.\n\n\nInstallation\n------------\n\n```python\npip install django-apscheduler\n```\n\n\nQuick start\n-----------\n\n- Add ``django_apscheduler`` to your ``INSTALLED_APPS`` setting like this:\n```python\nINSTALLED_APPS = (\n # ...\n \"django_apscheduler\",\n)\n```\n\n- django-apscheduler comes with sensible configuration defaults out of the box. The defaults can be overridden by adding\n the following settings to your Django `settings.py` file:\n```python\n# Format string for displaying run time timestamps in the Django admin site. The default\n# just adds seconds to the standard Django format, which is useful for displaying the timestamps\n# for jobs that are scheduled to run on intervals of less than one minute.\n# \n# See https://docs.djangoproject.com/en/dev/ref/settings/#datetime-format for format string\n# syntax details.\nAPSCHEDULER_DATETIME_FORMAT = \"N j, Y, f:s a\"\n\n# Maximum run time allowed for jobs that are triggered manually via the Django admin site, which\n# prevents admin site HTTP requests from timing out.\n# \n# Longer running jobs should probably be handed over to a background task processing library\n# that supports multiple background worker processes instead (e.g. Dramatiq, Celery, Django-RQ,\n# etc. See: https://djangopackages.org/grids/g/workers-queues-tasks/ for popular options).\nAPSCHEDULER_RUN_NOW_TIMEOUT = 25 # Seconds\n```\n\n- Run `python manage.py migrate` to create the django_apscheduler models.\n\n- Add a [custom Django management command](https://docs.djangoproject.com/en/dev/howto/custom-management-commands/) to your project\n that schedules the APScheduler jobs and starts the scheduler:\n \n```python\n# runapscheduler.py\nimport logging\n\nfrom django.conf import settings\n\nfrom apscheduler.schedulers.blocking import BlockingScheduler\nfrom apscheduler.triggers.cron import CronTrigger\nfrom django.core.management.base import BaseCommand\nfrom django_apscheduler.jobstores import DjangoJobStore\nfrom django_apscheduler.models import DjangoJobExecution\nfrom django_apscheduler import util\n\nlogger = logging.getLogger(__name__)\n\n\ndef my_job():\n # Your job processing logic here...\n pass\n\n\n# The `close_old_connections` decorator ensures that database connections, that have become\n# unusable or are obsolete, are closed before and after your job has run. You should use it\n# to wrap any jobs that you schedule that access the Django database in any way. \n@util.close_old_connections\ndef delete_old_job_executions(max_age=604_800):\n \"\"\"\n This job deletes APScheduler job execution entries older than `max_age` from the database.\n It helps to prevent the database from filling up with old historical records that are no\n longer useful.\n \n :param max_age: The maximum length of time to retain historical job execution records.\n Defaults to 7 days.\n \"\"\"\n DjangoJobExecution.objects.delete_old_job_executions(max_age)\n\n\nclass Command(BaseCommand):\n help = \"Runs APScheduler.\"\n\n def handle(self, *args, **options):\n scheduler = BlockingScheduler(timezone=settings.TIME_ZONE)\n scheduler.add_jobstore(DjangoJobStore(), \"default\")\n\n scheduler.add_job(\n my_job,\n trigger=CronTrigger(second=\"*/10\"), # Every 10 seconds\n id=\"my_job\", # The `id` assigned to each job MUST be unique\n max_instances=1,\n replace_existing=True,\n )\n logger.info(\"Added job 'my_job'.\")\n\n scheduler.add_job(\n delete_old_job_executions,\n trigger=CronTrigger(\n day_of_week=\"mon\", hour=\"00\", minute=\"00\"\n ), # Midnight on Monday, before start of the next work week.\n id=\"delete_old_job_executions\",\n max_instances=1,\n replace_existing=True,\n )\n logger.info(\n \"Added weekly job: 'delete_old_job_executions'.\"\n )\n\n try:\n logger.info(\"Starting scheduler...\")\n scheduler.start()\n except KeyboardInterrupt:\n logger.info(\"Stopping scheduler...\")\n scheduler.shutdown()\n logger.info(\"Scheduler shut down successfully!\")\n\n```\n\n- The management command defined above should be invoked via `./manage.py runapscheduler` whenever the webserver serving\n your Django application is started. The details of how and where this should be done is implementation specific, and\n depends on which webserver you are using and how you are deploying your application to production. For most people\n this should involve configuring a [supervisor](http://supervisord.org) process of sorts.\n\n- Register any APScheduler jobs as you would normally. Note that if you haven't set `DjangoJobStore` as the `'default'`\n job store, then you will need to include `jobstore='djangojobstore'` in your `scheduler.add_job()` calls.\n\n\nAdvanced usage\n--------------\n\ndjango-apscheduler assumes that you are already familiar with APScheduler and its proper use. If not, then please head\nover to the project page and have a look through\nthe [APScheduler documentation](https://apscheduler.readthedocs.io/en/latest/index.html).\n\nIt is possible to make use\nof [different types of schedulers](https://apscheduler.readthedocs.io/en/latest/userguide.html#choosing-the-right-scheduler-job-store-s-executor-s-and-trigger-s)\ndepending on your environment and use case. If you would prefer running a `BackgroundScheduler` instead of using a\n`BlockingScheduler`, then you should be aware that using APScheduler with uWSGI requires some additional\n[configuration steps](https://apscheduler.readthedocs.io/en/latest/faq.html#how-can-i-use-apscheduler-with-uwsgi) in\norder to re-enable threading support.\n\n\nSupported databases\n-------------------\n\nPlease take note of the list of databases that\nare [officially supported by Django](https://docs.djangoproject.com/en/dev/ref/databases/#databases). django-apscheduler\nprobably won't work with unsupported databases like Microsoft SQL Server, MongoDB, and the like.\n\n\nDatabase connections and timeouts\n---------------------------------\n\ndjango-apscheduler is dependent on the standard Django\ndatabase [configuration settings](https://docs.djangoproject.com/en/dev/ref/databases/#general-notes). These settings,\nin combination with how your database server has been configured, determine how connection management will be performed\nfor your specific deployment.\n\nThe `close_old_connections` decorator should be applied to APScheduler jobs that require database access. Doing so\nensures that Django's [CONN_MAX_AGE](https://docs.djangoproject.com/en/dev/ref/settings/#std:setting-CONN_MAX_AGE)\nconfiguration setting is enforced before and after your job is run. This mirrors the standard Django functionality of\ndoing the same before and after handling each HTTP request.\n\nIf you still encounter any kind of 'lost database connection' errors then it probably means that:\n\n- Your database connections timed out in the middle of executing a job. You should probably consider incorporating a\n connection pooler as part of your deployment for more robust database connection management\n (e.g. [pgbouncer](https://www.pgbouncer.org) for PostgreSQL, or the equivalent for other DB platforms).\n- Your database server has crashed / been restarted.\n Django [will not reconnect automatically](https://code.djangoproject.com/ticket/24810)\n and you need to re-start django-apscheduler as well.\n\nCommon footguns\n---------------\n\nUnless you have a very specific set of requirements, and have intimate knowledge of the inner workings of APScheduler,\nyou really shouldn't be using `BackgroundScheduler`. Doing so can lead to all sorts of temptations like:\n\n* **Firing up a scheduler inside of a Django view:** this will most likely cause more than one scheduler to run\n concurrently and lead to jobs running multiple times (see the above introduction to this README for a more thorough\n treatment of the subject).\n* **Bootstrapping a scheduler somewhere else inside your Django application**: it feels like this should solve the\n problem mentioned above and guarantee that only one scheduler is running. The downside is that you have just delegated\n the management of all of your background task processing threads to whatever webserver you are using (Gunicorn, uWSGI,\n etc.). The webserver will probably kill any long-running threads (your jobs) with extreme prejudice (thinking that\n they are caused by misbehaving HTTP requests).\n\nRelying on `BlockingScheduler` forces you to run APScheduler in its own dedicated process that is not handled or\nmonitored by the webserver. The example code provided in `runapscheduler.py` above is a good starting point.\n\n\nProject resources\n-----------------\n\n- [Changelog](docs/changelog.md)\n- [Release procedures](docs/releasing.md)\n\n\n",
"bugtrack_url": null,
"license": "MIT",
"summary": "APScheduler for Django",
"version": "0.6.2",
"project_urls": {
"Homepage": "http://github.com/jcass77/django-apscheduler"
},
"split_keywords": [
"django",
"apscheduler",
"django-apscheduler"
],
"urls": [
{
"comment_text": "",
"digests": {
"blake2b_256": "bee6317136821a62aa22f078b4447b72fe773027bae48df36aaf649317e048a3",
"md5": "547851e1f3df7851f41f72c6192b083f",
"sha256": "d30a05be98e01c12aa50d0a7afd8d0fd529c874d1c75af20891b6417d2f36475"
},
"downloads": -1,
"filename": "django_apscheduler-0.6.2-py3-none-any.whl",
"has_sig": false,
"md5_digest": "547851e1f3df7851f41f72c6192b083f",
"packagetype": "bdist_wheel",
"python_version": "py3",
"requires_python": null,
"size": 24653,
"upload_time": "2022-03-06T04:24:02",
"upload_time_iso_8601": "2022-03-06T04:24:02.646640Z",
"url": "https://files.pythonhosted.org/packages/be/e6/317136821a62aa22f078b4447b72fe773027bae48df36aaf649317e048a3/django_apscheduler-0.6.2-py3-none-any.whl",
"yanked": false,
"yanked_reason": null
},
{
"comment_text": "",
"digests": {
"blake2b_256": "37a23815e39c3ec7c83c721d9330380b2afad97b8fee9e83d19b23d4a47235f8",
"md5": "68edd4f7e53b201c7bdd0422875299e5",
"sha256": "60ced2c07b531b0477076dfef2d6de4790a983a4bbd75fae5e387ac360e9c8fd"
},
"downloads": -1,
"filename": "django-apscheduler-0.6.2.tar.gz",
"has_sig": false,
"md5_digest": "68edd4f7e53b201c7bdd0422875299e5",
"packagetype": "sdist",
"python_version": "source",
"requires_python": null,
"size": 465647,
"upload_time": "2022-03-06T04:24:05",
"upload_time_iso_8601": "2022-03-06T04:24:05.283893Z",
"url": "https://files.pythonhosted.org/packages/37/a2/3815e39c3ec7c83c721d9330380b2afad97b8fee9e83d19b23d4a47235f8/django-apscheduler-0.6.2.tar.gz",
"yanked": false,
"yanked_reason": null
}
],
"upload_time": "2022-03-06 04:24:05",
"github": true,
"gitlab": false,
"bitbucket": false,
"codeberg": false,
"github_user": "jcass77",
"github_project": "django-apscheduler",
"travis_ci": false,
"coveralls": true,
"github_actions": true,
"lcname": "django-apscheduler"
}
JSON
