* test: fix flaky RQ job tests
Sometimes stop_job doesn't succeed and causes tests to timeout. Reduced
sleep time to avoid this in tests. We are still testing all the
important features - monitoring.
* build(deps): Bump RQ to latest version
Minor bugfixes that affect us
ref: https://github.com/rq/rq/releases
* test: sanity tests for scheduled job types
* test(test_runner): dont set bench_id globally
* refactor: stop_job shouldn't throw error
The intention of use here is to stop stuck jobs or long running jobs, if
for some reason they were stopped by the time command gets executed,
there's no need to throw error.
Werkzeug reloader is right now using an inefficient `stat` based reloader which is horrible on large codebases with low-powered devices.
Difference:
- `stat` based reloader basically checks each and every file if they have changed or not.
- watchdog subscribes to platform specific change events on kernel (like kqueue, fsevents or inotify )
Given how widespread PY310's usage has become, and how we're just a
few months away from PY311 major release. This is a slightly late
bumping but necessary to ensure smoother updates & maintenance for
Frappe, ERPNext & other apps in the coming years. Almost all people
who participated in the pool from the community as well as Frappe team
voted (via active telegram groups) PY310 as their preferred minimum
requirement for v14.
* build: Use toml defined dev dependencies over txt file
* chore: Remove redundant ==
* ref: https://github.com/frappe/bench/releases/tag/v5.12.1
* Linter's style updates
* chore(deps): Bump coverage from 5.5 to ~=6.4.1
There was an attempt to switch to declarative setup, which was to use
setup.cfg. However, we've made more progress in the "world of packaging"
since. Also, given we're using a pyproject file already to govern
certain aspects of our project maintenance, it's probably a good time to
bring these things together. bye-bye to clutter and confusion in
maintaining multiple files and formats.
We've used setuptools to package frappe for the longest time. Maybe
since the first editable installation. Howver setuptools doesn't support
PEP 660 yet which supports editable installs via pyproject file.
So why now? Primarily because I wanted to start tracking system
dependencies for Frappe. Doing so through pyproject file made the most
sense. This change seemed to be the obvious pre-requisite for the
upcoming changes to our packaging systems.
Sys deps tracking: https://github.com/frappe/frappe/issues/13811
Flit docs: https://flit.pypa.io/en/latest/pyproject_toml.html
Previous attempt: https://github.com/frappe/frappe/pull/10773
Which build tool: https://stackoverflow.com/a/69711730/10309266
PEP 660: https://peps.python.org/pep-0660/
