From: Thomas H. <th...@py...> - 2004-07-28 18:19:14
|
(Well, someone said he would wait for 0.6 for this to appear. Maybe he was right after all) I have single file executables running as a proof of concept. The reason I want to do this may *not* be what most people want (to deploy only a single file), the reason for me is that this allows complete isolation of dll com servers one from each other, and from the executable they run in - because there is no longer a shared python.dll used by all this components. Instead, a Python interpreter is contained *statically* in the exe-stubs that py2exe uses (run.exe, run_w.exe, later even run_dll.dll). The library.zip file, containing the pure python modules, is appended to the exe as they were in older py2exe versions (it would as well be possible to use the frozen-module mechanism instead of the zipimport, like cx_Freeze does it). The disadvantage, of course, is that it is no longer possible for the exe or dll to import _any_ extension modules from the file system, because the normal extension modules cannot link back to the exe. This means that _any_ extension modules you wanted to use *must* be builtin modules. Now, how can this be achived? So far, here are the ideas. First, prebuilt exe stubs can be provided by the py2exe installer, which would contain most of the standard extensions distributed by the python.org installer (plus _ctypes, of course ;-). But this wouldn't allow using the pywin32 extensions, for example - unless some kind soul builds all of them into the exe stubs as well. Second, the exe stubs could be built (if a C compiler is installed) at runtime when py2exe runs. py2exe would collect the extension modules needed, build a config.c file at runtime, and compiles this, linking to static libraries of pywin32, wxPython, or whatever. Comments? Thomas |
From: Brad C. <bkc@Murkworks.com> - 2004-07-30 17:20:26
|
"Thomas Heller" <th...@py...> wrote in message news:vfg...@py...... > The reason I want to do this may *not* be what most people want (to > deploy only a single file), the reason for me is that this allows > complete isolation of dll com servers one from each other, and from the > executable they run in - because there is no longer a shared python.dll > used by all this components. Is this really a problem on win32 systems? I thought that only the code is shared for loaded dll objects, and that DLL based globals are in the user's process space. Perhaps I don't understand the problem enough :-( |
From: Thomas H. <th...@py...> - 2004-07-30 20:01:15
|
"Brad Clements" <bkc@Murkworks.com> writes: > "Thomas Heller" <th...@py...> wrote in message > news:vfg...@py...... > >> The reason I want to do this may *not* be what most people want (to >> deploy only a single file), the reason for me is that this allows >> complete isolation of dll com servers one from each other, and from the >> executable they run in - because there is no longer a shared python.dll >> used by all this components. > > Is this really a problem on win32 systems? > > I thought that only the code is shared for loaded dll objects, and that DLL > based globals are in the user's process space. Yes, it is a problem. For example, you cannot use frozen dll com servers in a Python client program, at least if both use the same Python version - the python23.dll is shared between all of these, as well as sys.modules, the interpreter lock, sys.path, and so on. The situation may be better if each would use a separate interpreter, but this only moves the problem into the extension modules - they are still shared. Thomas |
From: Brad C. <bkc@Murkworks.com> - 2004-08-02 19:41:30
|
_ "Thomas Heller" <th...@py...> wrote in message news:y8l...@py...... > Yes, it is a problem. For example, you cannot use frozen dll com > servers in a Python client program, at least if both use the same Python > version - the python23.dll is shared between all of these, as well as > sys.modules, the interpreter lock, sys.path, and so on. The situation > may be better if each would use a separate interpreter, but this only > moves the problem into the extension modules - they are still shared. I see. It's a problem for inproc servers. But, presumably, not a problem for out-of-proc servers? Anyway, having only one file to rely on would be great anyway, that way if the user deletes it they won't be able to get a strange runtime error. ;-) |
From: Brian D. <bri...@gm...> - 2004-07-31 03:14:43
|
I'm re-sending this because I accidentally sent it to just Thomas, rather than the list. =========================================================== Thomas, I'm personally very glad you're thinking about this! For most of my projects I'm quite happy with the current directory layout, but sometimes it would be very nice to hand off small tools to co-workers as single executables. As a single point of data, here is the lib dir for my most complicated project (includes various scripts and two services): 12/18/2003 09:27p 45,123 datetime.pyd 09/26/1998 01:00a 995,383 MFC42.DLL 11/04/2003 10:52a 28,728 perfmon.pyd 11/04/2003 10:52a 323,649 pythoncom23.dll 11/04/2003 10:52a 86,084 pywintypes23.dll 12/18/2003 09:28p 20,545 select.pyd 11/04/2003 10:52a 32,831 servicemanager.pyd 06/29/2004 09:59a 2,131,980 shared.zip 12/18/2003 09:25p 16,384 w9xpopen.exe 11/04/2003 10:52a 69,689 win32api.pyd 11/04/2003 10:52a 28,731 win32event.pyd 11/04/2003 10:52a 28,732 win32evtlog.pyd 11/04/2003 10:52a 28,733 win32service.pyd 11/04/2003 10:52a 639,036 win32ui.pyd 12/18/2003 09:30p 61,503 zlib.pyd 01/15/2004 02:45p 61,440 _ctypes.pyd 12/18/2003 09:25p 49,218 _socket.pyd 12/18/2003 09:25p 57,407 _sre.pyd 12/18/2003 09:26p 495,616 _ssl.pyd 12/18/2003 09:29p 36,864 _winreg.pyd 20 File(s) 5,237,676 bytes On Wed, 28 Jul 2004 20:18:48 +0200, Thomas Heller <th...@py...> wrote: > So far, here are the ideas. > > First, prebuilt exe stubs can be provided by the py2exe installer, > which would contain most of the standard extensions distributed by the > python.org installer (plus _ctypes, of course ;-). But this wouldn't > allow using the pywin32 extensions, for example - unless some kind soul > builds all of them into the exe stubs as well. Sounds good for the most common cases. > Second, the exe stubs could be built (if a C compiler is installed) at > runtime when py2exe runs. py2exe would collect the extension modules > needed, build a config.c file at runtime, and compiles this, linking to > static libraries of pywin32, wxPython, or whatever. I'm not much of a C guy... but if the setup instructions were clear, I'd probably make an attempt to get this going. On the other hand... if this system existed, could someone who did have a compiler all setup properly build them and make them available to me using the first option? Take care, -Brian |
From: Chris L. <cli...@gm...> - 2004-07-31 19:18:46
|
Brian Dorsey wrote: > On Wed, 28 Jul 2004 20:18:48 +0200, Thomas Heller <th...@py...> wrote: > >>So far, here are the ideas. >> >>First, prebuilt exe stubs can be provided by the py2exe installer, >>which would contain most of the standard extensions distributed by the >>python.org installer (plus _ctypes, of course ;-). But this wouldn't >>allow using the pywin32 extensions, for example - unless some kind soul >>builds all of them into the exe stubs as well. > > Sounds good for the most common cases. > > >>Second, the exe stubs could be built (if a C compiler is installed) at >>runtime when py2exe runs. py2exe would collect the extension modules >>needed, build a config.c file at runtime, and compiles this, linking to >>static libraries of pywin32, wxPython, or whatever. > > I'm not much of a C guy... but if the setup instructions were clear, > I'd probably make an attempt to get this going. On the other hand... > if this system existed, could someone who did have a compiler all > setup properly build them and make them available to me using the > first option? using a C compiler with distutils is realy easy. getting hands on a free C compiler isn't that complicated neither. tough i dont have seen a all in once installer. there are two impls of GCC: - http://mingw.org/ get gcc, binutils and the windows api files, make sure it's install location is in the $PATH variable (thats the small variant if you just want a compiler) - http://cygwin.com/ get setup.exe, run it. then select "install from internet" select devel/gcc mingw and binutils packages. (this is the larger variant, gcc installs a lot of un*x compatibily tools too and it provides a POSIX emulation. it also has it's own python version, you don't need that usualy) then to compile and install extensions (in both cases) use python setup.py build --compiler=mingw32 install as long as you dont need to debug broken packages, you probably don't even care if there is a C compiler running or not.. when py2exe would use the distutils stuff to run the compiler i wouldn't see a problem to compile custom exe stubs for "non-C" people. some time ago, i have once played around using distutils to create custom DLLs with an embedded python interpreter. i had to implement a custom distutils command (a variant of the extensions builder), but that's no problem, thats the same that py2exe does :-) maybe it would be helpful if there was a all in one installer for the gcc compiler, so that one does not have to get several archives. but i think the compiler and py2exe should be separate, as some people would like to use other compilers for some reasons (strange reasons ;-) and not everyone needs the compiler and it adds quite some bytes to the download size. chris |