py2exe service and tool-tray app combined?

Brad Clements bkc at murkworks.com
Thu Aug 14 14:10:09 EDT 2003


On 14 Aug 2003 at 19:17, Thomas Heller wrote:

> 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 think a py2exe specific mailing list would be best. You could probably just use one on 
SF like venster does.


> > 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).

I hvaen't looked at the source yet, but perhaps it would be enough to 'emulate' 
win32serviceutil.HandleCommandLine like pythonservice.exe does.

This way, a person could create a service using pythonservice.exe, and then package 
with py2exe without changing the code at all.

And, in my case I could parse the command line before calling  
win32serviceutil.HandleCommandLine and do something different, like showing a 
tooltray app or something instead.

> But I'm not sure it makes sense nowadays - win98 is history.

ha ha,  tell the customer!

> 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 sounds good. So then all we'd need is changes to the packaging mechanism to 
group 'specified packages' into their own zip file external to the .exe, specify the order 
in which these .zip files get placed into sys.path, and have the .exe do this path 
munging when it starts.

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

Sure, its all nice, but maybe a bit overkill. Supports we just had 0 or more 'external' 
import zips stuck into sys.path in an order we desired.

I'm assuming that packages have to completely fit into a single .zip. So upgrading 
would require putting the entire contents of the 'updated' package into a new .zip file 
that goes into the path before the old .zip

In my use cases, I only need one (maybe 2) external .zips and I'd just upgrade the 
entire .zip in one shot. These will always be much smaller than python23.zip anyway.



-- 
Brad Clements,                bkc at murkworks.com   (315)268-1000
http://www.murkworks.com                          (315)268-9812 Fax
http://www.wecanstopspam.org/                   AOL-IM: BKClements






More information about the Python-list mailing list