[Distutils] entry point for new installations?
Phillip J. Eby
pje at telecommunity.com
Mon Mar 20 23:11:59 CET 2006
At 04:02 PM 3/20/2006 -0500, Kevin Dangoor wrote:
>Someone just prodded me about automatic application reloading, which
>is always a hairy topic. The autoreload code that many people run in
>development mode forks to run the actual application in a child
>process, and everything in sys.modules is watched for a change. If one
>of the files change, the child exits and the parent process fires off
>a new one. It's ugly, but it's reliable and is generally fine for
>development.
>
>For TurboGears apps, I'm of the opinion that the right way to deploy
>an app to production is to turn it into an egg and install it. I had
>the (not entirely fleshed out) thought that it might be interesting if
>there was an entry_point that got called when new eggs were installed.
>This would make it possible to notify a running server that it needs
>to be restarted.
>
>Thoughts?
An entry point won't really help you much here, because it would have to
know how to perform this notification. Presumably, it would either have to
talk to a socket or modify a file somewhere.
However, if you're going to have to monitor for file changes anyway, then
you might as well just monitor sys.path directories for new .egg files, or
monitor changes to easy-install.pth files.
The only other thing I can think of that would work is if you had server
processes write their process IDs some place, and then the hypothetical
entry point could send them SIGHUPs or something. But monitoring
file/directory changes is a bit more cross-platform, doesn't require adding
any entry point code, is probably part of existing reload code, and doesn't
require a pidfile arena, with all the associated permissions and cleanup
headaches thereof.
More information about the Distutils-SIG
mailing list