py2exe service and tool-tray app combined?

[Thomas Heller]

"Brad Clements" <bkc at murkworks.com> writes:

> Once again I apologize for posting this py2exe question in the ctypes list. ;-)

In the long run, this will be the wrong forum. I suggest
comp.lang.python (or should a py2exe mailing list be created?).
And I'm cc'ing to python-list.

>
> I need to ship a Windows service in py2exe, but I also want a
> tool-tray control application (I'll make with venster or win32gui)
>
> Naturally I want to save space. Can I do this with one .exe?
>
> It's not clear from the project page what gets executed when the
> service .exe is run without -debug or -register.

Well, you can try it out. But IIRC, nothing useful will happen. The
service tries to start, but cannot because it cannot connect to the
service manager (or something like that).

> Can I have a single .py file that has win32serviceutil.ServiceFramework subclass and the usual
>
> if __name__ == "__main__":
>
> And if I do this, how do I handle -register and -unregister?

I don't think so. But look into the C code run_svc.c to be sure.

> Also, if anyone knows, I assume services don't run on 9x, so I want to 'simulate' a 
> service there by having the same .exe do all the work (and appear as a tooltray app), 
> so here's another reason for having one .exe
>
> Can it be done?
>
Not sure. Best would be to change the win32all serviceutil framework.
But I'm not sure it makes sense nowadays - win98 is history.

> --
>
> And while I'm bugging the list, one thing I'd like to be able to do is
> to split my application files into their own .zip distinct from 'the
> python library .zip bolted onto the .exe'.

Well, I have something for you. As time permits, I'm working on a new
py2exe using the zipimport of Python 2.3. Still very much work in
progress, and services are not yet supported, but it's already in CVS in
a sandbox subdirectory.

> That is, be able to define a group of .py files or packages that
> should go into their own zip file outside the .exe, with that .zip
> being inserted into sys.path before the .zip that's built into the
> .exe

This py2exe (optionally) allows to create a number of console, gui exe
files, together with exe files implementing localserver and inproc COM
servers. The exe (or dll) files only contain the main script, or a
'boot' script for the com and service. The remaining code is loaded from
a shared zipfile.

>
> This way, when I want to ship an 'upgrade' I most likely only need to
> send a small .zip file instead of a gigantic .exe
>
> So while declaring which packages or .py files are 'seperate' would be
> a pain, I think this would be very handy for making easy-to-web-update
> applications.
>
> Comments?

This reminds me of how applications for Visual Smalltalk were
distributed. We had a small exe of only a could of kilobytes, this was
renamed into something like 'myapp.exe'. The classes neede were packed
into .sll files - smalltalk link libraries. And you had to provide a
'myapp.bnd' file which listed all the .sll files needed by 'myapp.exe'.

If you discovered a bug in an .sll file, you could either buid and
distribute a new version of it, or you could create an additional, new
.sll file containing the fixed methods. And you would make sure to list
this new .sll in the myapp.bnd file, before the buggy one. This way the
size of the upgrade could be kept as small as possible.

Now, isn't this '.bnd' file mechanism also a nice idea for py2exe?

Thomas