huy said:
Great idea Daniel. An SVN client would work well. I'll think about it
for a while but I think this would be a real option.
SVN sounds attractive because, among other things, it's _designed_ to be
scripted with Python (and no doubt in other ways, but I've noticed the
Python part only). However, it sounds as if all you need is some
variant of "os.system('svn up')" at program start (_before_ importing
any module that is part of the app), so that 'cvs up' or any other
revision control system would be just as fine.
And most likely so would be a roll-your-own approach, which might go
something like...:
def check_for_updates(
local_ver_filepath, #where we remember version
remote_ver_url, #where the server does
local_zip_filepath, #where we keep the modules' zipfile
remote_zip_url, #where the server does
report_fun=None, #how to give feedback of downloads
):
# let's see if there have been any updates since we last ran
current_local_version = open(local_ver_filepath).read()
current_remote_version = urrlib.urlopen(remote_ver_url).read()
if current_local_version >= current_remote_version:
# nope, no update needed, let caller know
return False, current_local_version, current_remote_version
# updates! get the new set of modules into the right place
urllib.urlretrieve(remote_zip_url, local_zip_filepath, report_fun)
# make sure the modules' zipfile is on the sys.path
import sys
if local_zip_filepath not in sys.path:
sys.path.insert(0, local_zip_filepath)
# record out latest update, for the future
open(local_ver_filepath,'w').write(current_remote_version)
# let caller know we did perform an update
return True, current_local_version, current_remote_version
There -- in barebones term, isn't that roughly what you need? Sure, you
can conceive enhancements of it, a lot of them -- enhanced error
handling (this one doesn't DO much...
, a log of what was updated when
(that might take the place of the tiny local_ver_filepath file), keeping
version numbers in the same zipfile as the modules rather than in a
small separate file (you still want a separate URL on the server so you
can check that no update is needed as fast as possible, of course), etc,
etc. But, roughly speaking, it does appear to me that this
twelve-statements-or-less function just ight meet your need even better
than svn or cvs would... depending on your exact needs, of course!-)
This one relies on Python's ability to import from a zipfile (of course,
you _could_ easily unzip the file after downloading it if you wanted,
but still it hinges on the concept of one update == one download). If
your typical update is a module or two out of dozens making up your app,
this would be suboptimal -- you'd waste a lot of bandwidth repeating the
download of modules that are already just fine. svn or cvs would be
better here. Alternatively, if you're willing to assume more cleverness
server-side, you could get by with a single roundtrip -- s/thing like:
filepath, msg = urlretrieve(server_url % current_local_version)
if the current local version is already OK, the server would return an
empty file and a msg with some appropriate header you can test;
otherwise the server would zip, or better tar and gzip (or bzip2, even
better) the needed set of modules, based on the current local version
and the current remote/centralized on, and send that as the response,
with a msg with some headers that can be tested for that. Of course,
the _server_ could perfectly well use svn or cvs to keep track of what
modules must go into the archive. And while this does require a modicum
of intelligence on the server, it's nothing a perfectly plain CGI would
have any trouble doing.
The client would test the appropriate header of msg, then, if needed,
unzip or otherwise uncompress the filepath and finally remove it.
One advantage of each of these approaches is that you minimize what you
need to install on the client -- no need for any cvs or svn and thus
also no need for any of the dependencies of those systems. Any good old
plain vanilla Python installation on the client would suffice...
Alex
