Newer versions of python dependencies

[LanetheGreat]

I was looking for a good cron replacement for Debian (stretch) that could support multi-user access (or at least work from behind Apache/Nginx) and came across your guys' library, but noticed that most of the library dependencies that are already in the Debian APT repo are newer than this library's current setup. I was hoping to make Debian python packages out of your library and get them submitted to be used in Debian's main repo branch, so I forked it and made some patches to get its setup to pass during packaging and did successfully make a usable library packages out of it for python 2 and 3 separately.

I also did some testing with newer versions of the dependencies to see what were the latest it could run with without causing serious issues, since Debian will slowly use newer and newer packages with each release. I did my testing on my Win10 laptop using python 3.6.4+pipenv and a RaspberryPI 2 running Debian (stretch-armhf) using Python 2.7.13 & Python 3.5.3 to run the packaged versions. I also tested what would happen to the jobs and database (SQLite) if swapping from old to new to old again to see if there would be issues while trying to revert to an older version.

These were what I was able to conclude from my tests:

• SQLAlchemy, python-future, python-dateutil, requests and mock were all able to run fine on their latest versions.
• Tornado was able to run fine all the way up until v6. In v6 they made incompatible changes to @tornado.gen.engine and @tornado.web.asynchronous, which will have to be reworked in ndscheduler to make its API compatible.
• APscheduler was able to run fine on any version but did create backwards incompatible changes to any jobs in the database either created or modified after the upgrade. Although:
  • v3.1.0 is completely backwards compatible without changing the database.
  • v3.2.0+ apscheduler.triggers.con.CronTrigger becomes un-unpickelable from the db when reverting back because the pickling/unpickling process was changed in this version, but the jobs will fail on trying to be read or executed.
  • v3.5.0+ In apscheduler.triggers.cron.field the MonthField field was introduced into triggers, so all new and modified jobs will be unpickelable when switching back and will be deleted automatically by apscheduler when reverted back from this version.

Debian, as of this PR writing, has deb's for both apscheduler 3.3.1 and 3.5.3 in the main repo. I would recommend that anybody planning on reverting back to using an older version of apscheduler after using this fork to backup their job database, otherwise everything runs fine on the newer versions.
It is also currently using tornado 4.4.3 so that should be safe for a while before being upgraded to v6.

[sabw8217]

@LanetheGreat thanks for your contribution, this looks great!

I will add something to the README about recommending that you backup your database when upgrading. Hopefully most people would do that anyhow 😄 but always good to put a reminder in there.