[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