> > Better suggestion: just append a PEP 441 .pyz to the .exe, and no >
IIUC PEP 441 is about tooling to create archives; don't we just need a Python-compatible .zip (i.e. with a __main__.py)? > For bonus points, you can actually stick a compatibly-built wheel on > the end of the .exe instead, and embed the entire relevant project. > ;-) This is less helpful; one might have N scripts per project, no need to stick the whole project in with each one, or am I misunderstanding? > Writing the script.py file means the current user needs write access > to a program installation directory, which is probably not a good True. > idea. Also, what if two instances are running, or you overwrite an > existing script while it's being read by Python in another process? That could probably be taken care of with a bit of footwork. > No, if you're taking the embedding route, it's got to be either a > zipfile, or else you have to use -c and give Python an offset to seek > to in the file. How would such an offset be used? Are you saying the -c scriptlet would use that offset to extract the script? Or do you mean something else? > (As for ctypes, if that's needed for this approach (which I somewhat > doubt), there are official Windows binaries available for 2.3 and > 2.4.) It's needed only if you use the specific approach I used - which was to use the Windows UpdateResource API to embed the script as a pukka Windows resource. Of course, if you're just appending something to the .exe, you don't need ctypes. Regards, Vinay Sajip _______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
