It would be good to do some maintenance on the base of your application.
Although it run well for now, your application server (cherrypy2) is going old and unmaintained.
We are trying to push SABNzbd in portage, but this requirement (cherrypy2) is a big stopper.
See http://bugs.gentoo.org/show_bug.cgi?id=132590.
Even of the incompatible changes, the cherrypy3 port is not that difficult and will bring you more users.
Another linked improvement would be to package it as an egg and deploy the script as a "console_script" entry point.
This would be a lot more python sympathic and a lot of more flexible.
It will make also your distributions packagers work a lot easier.
CherryPy3 / WSGI support
Re: CherryPy3 / WSGI support
We have done the port for the pending release 0.5.0.
It was definitely not an easy job.
The CherryPy people must enjoy creating porting problems and their releases
generally lack both backward and forward compatibility.
The 0.5.0 release uses a 3-4 month old SVN snapshot, because their latest official release
doesn't cut it and their latest trunk presents again new incompatibilities.
What's the problem with CherryPy in the distribution? We already carry our own
specific version, because of compatibility problems. Since it's pure Python, making
it part of out distro is easy.
Sorry to sound sour, but CherryPy is a constant source of headache for us.
If it wasn't so much work, we would gladly replace it with something else.
I don't know about the "egg" suggestion.
JCPF seems to be doing a good job with his Ubuntu package.
I don't really understand why people insist on treating SABnzbd as a Python module,
while it isn't.
From what little I know of the Python "scene", the "egg-thing" isn't exactly universally popular.
It was definitely not an easy job.
The CherryPy people must enjoy creating porting problems and their releases
generally lack both backward and forward compatibility.
The 0.5.0 release uses a 3-4 month old SVN snapshot, because their latest official release
doesn't cut it and their latest trunk presents again new incompatibilities.
What's the problem with CherryPy in the distribution? We already carry our own
specific version, because of compatibility problems. Since it's pure Python, making
it part of out distro is easy.
Sorry to sound sour, but CherryPy is a constant source of headache for us.
If it wasn't so much work, we would gladly replace it with something else.
I don't know about the "egg" suggestion.
JCPF seems to be doing a good job with his Ubuntu package.
I don't really understand why people insist on treating SABnzbd as a Python module,
while it isn't.
From what little I know of the Python "scene", the "egg-thing" isn't exactly universally popular.