From: Geoff B. <geo...@je...> - 2008-06-11 09:20:57
|
Hi, My application has several different python executables, and so far requires an install of Python on the machine. I've realised, though, that for quite involved reasons (can explain if needed) it would be very useful to convert one of the simpler scripts to an executable, so have done that. However, as the application as a whole requires Python to be installed anyway it feels a bit odd to be distributing things copied directly from the python distribution. Is there some way to tell py2exe not to do that and create an executable that can automatically find a python distribution from the registry and use the files from that? Regards, Geoff Bache |
From: Thomas H. <th...@ct...> - 2008-06-11 09:46:55
|
Geoff Bache schrieb: > Hi, > > My application has several different python executables, and so far > requires an install of Python on the machine. I've realised, though, > that for quite involved reasons (can explain if needed) it would be > very useful to convert one of the simpler scripts to an executable, > so have done that. I can think of a few reasons for this myself, so you don't have to explain (unless it is an interesting explaination). > However, as the application as a whole requires Python to be > installed anyway it feels a bit odd to be distributing things copied > directly from the python distribution. Is there some way to tell > py2exe not to do that and create an executable that can automatically > find a python distribution from the registry and use the files from > that? I believe that setuptools (when creating eggs?) does create small executables for the scripts, so this may be a better way for you. With py2exe, you *could* create the executables in the usual way, remove 'library.zip' from sys.path, find the installed Python and add the needed directories to sys.path. -- Thanks, Thomas |
From: Thomas H. <th...@ct...> - 2008-06-11 09:56:08
|
Thomas Heller schrieb: > With py2exe, you *could* create the executables in the usual way, > remove 'library.zip' from sys.path, find the installed Python and add > the needed directories to sys.path. > You must do this in the script that is frozen into the executable, of course. -- Thanks, Thomas |
From: Geoff B. <geo...@je...> - 2008-06-11 10:47:36
|
>> However, as the application as a whole requires Python to be >> installed anyway it feels a bit odd to be distributing things copied >> directly from the python distribution. Is there some way to tell >> py2exe not to do that and create an executable that can automatically >> find a python distribution from the registry and use the files from >> that? >> > > I believe that setuptools (when creating eggs?) does create small > executables for the scripts, so this may be a better way for you. > Thanks. It now occurs to me that perhaps all I need is a Windows batch file that does something like python myscript.py $* except I can't figure out how to do the UNIX "$*" on Windows. Any tips? Regards, Geoff |
From: Thomas H. <th...@ct...> - 2008-06-11 11:29:20
|
Geoff Bache schrieb: >>> However, as the application as a whole requires Python to be >>> installed anyway it feels a bit odd to be distributing things copied >>> directly from the python distribution. Is there some way to tell >>> py2exe not to do that and create an executable that can automatically >>> find a python distribution from the registry and use the files from >>> that? >>> >> >> I believe that setuptools (when creating eggs?) does create small >> executables for the scripts, so this may be a better way for you. >> > Thanks. It now occurs to me that perhaps all I need is a Windows batch > file that > does something like > > python myscript.py $* > > except I can't figure out how to do the UNIX "$*" on Windows. Any tips? python myscript.py %* It requires that python.exe is on the PATH; the following might also work since .py files are associated with python.exe: myscript.py %* -- Thanks, Thomas |
From: Mark H. <mha...@sk...> - 2008-06-11 12:06:55
|
Thomas writes: > the following might also work > since .py files are associated with python.exe: > > myscript.py %* IIRC, .py must also be on your PATHEXT environment variable for this to work (I can't recall if the python installer adds this, but I think not) Cheers, Mark |
From: Geoff B. <geo...@je...> - 2008-06-11 12:49:02
|
Thomas Heller wrote: > Geoff Bache schrieb: > >>>> However, as the application as a whole requires Python to be >>>> installed anyway it feels a bit odd to be distributing things copied >>>> directly from the python distribution. Is there some way to tell >>>> py2exe not to do that and create an executable that can automatically >>>> find a python distribution from the registry and use the files from >>>> that? >>>> >>>> >>> I believe that setuptools (when creating eggs?) does create small >>> executables for the scripts, so this may be a better way for you. >>> >>> >> Thanks. It now occurs to me that perhaps all I need is a Windows batch >> file that >> does something like >> >> python myscript.py $* >> >> except I can't figure out how to do the UNIX "$*" on Windows. Any tips? >> > > python myscript.py %* > > It requires that python.exe is on the PATH; the following might also work > since .py files are associated with python.exe: > > myscript.py %* > Thanks for the tips. That seems to work, as far as it goes, but it seems I did need a .exe file after all... otherwise it only works when the program is started via the shell... If I create myscript.bat and from a python prompt run "subprocess.call(["myscript"])" this fails. With shell=True it works. However if I have myscript.exe instead it works with or without the shell... So now I need to either compile the .bat file (which seems like it requires commercial tools, grrr) or figure out setuptools. Or is there some other way to do this? (I'm basically trying to replicate the #!/usr/bin/env python syntax from UNIX, which works with or without the shell being explicitly used on startup) Regards, Geoff |
From: Thomas H. <th...@ct...> - 2008-06-11 13:25:24
|
Geoff Bache schrieb: > > Thanks for the tips. That seems to work, as far as it goes, but it > seems I did need a .exe file after all... otherwise it only works > when the program is started via the shell... > > If I create myscript.bat and from a python prompt run > "subprocess.call(["myscript"])" this fails. With shell=True it works. > However if I have myscript.exe instead it works with or without the > shell... AFAIK the shell is needed to start anything other than .exe files. > So now I need to either compile the .bat file (which seems > like it requires commercial tools, grrr) or figure out setuptools. Or > is there some other way to do this? I have never created packages or distributions with setuptools, but if I understand correctly it isn't that complicated. You write a simple setup-script which also imports setuptools, like this (untested!): """ import distutils import setuptools setup(name="something", scripts=['myscript.py', ...]) """ and then run 'python setup.py bdist_egg', which will create an egg that you or your customers can install and you/they will find executables for your script(s) in the c:\python25\scripts directory. > (I'm basically trying to replicate the #!/usr/bin/env python syntax > from UNIX, which works with or without the shell being explicitly > used on startup) This is getting off-topic for the py2exe list, you probably better ask on the python list or newsgroup. -- Thanks, Thomas |
From: Geoff B. <geo...@je...> - 2008-06-11 14:02:10
|
Hi again, >> So now I need to either compile the .bat file (which seems >> like it requires commercial tools, grrr) or figure out setuptools. Or >> is there some other way to do this? >> > > I have never created packages or distributions with setuptools, but > if I understand correctly it isn't that complicated. You write a simple > setup-script which also imports setuptools, like this (untested!): > > """ > import distutils > import setuptools > setup(name="something", scripts=['myscript.py', ...]) > """ > > and then run 'python setup.py bdist_egg', which will create an egg that > you or your customers can install and you/they will find executables for > your script(s) in the c:\python25\scripts directory. > > Yes, I made it that far. But the problem is that this means my customers have to understand what to do with python eggs. I was rather hoping I could build a .exe file myself and put it in the distribution, and that no further action would be required at the far end. >> (I'm basically trying to replicate the #!/usr/bin/env python syntax >> from UNIX, which works with or without the shell being explicitly >> used on startup) >> > > This is getting off-topic for the py2exe list, you probably better ask > on the python list or newsgroup. > Yes, I've been a bit off-topic all along. You've been very helpful anyway, thankyou. Regards, Geoff |
From: Daniel P. <da...@pr...> - 2008-06-12 02:57:58
|
Just curious: if you're going to want to invoke it from a Python process anyway (using subprocess.Popen or friends) then why not make your Python program notice that it's trying to launch a Python script and do an execfile instead? Or even parse the command line (I'm presuming you want to mix and match Python scripts and other executables) and look at the file extension: .exe and .com executed directly, .bat and .cmd get executed through the shell, .py through execfile or spawn a new Python executable, etc. Alternatively, it seems like a simple programming job in C to write a small stub that finds the Python environment via the registry and invokes it. (I know of several comparable launcher stubs for Java: winrun4j.sf.net and javaservice.objectweb.org come immediately to mind.) You could write a simple launcher stub in about 10-20 lines of C# but I don't think you want the .NET dependency. Straight Win32 C is a bit more complex but not impossibly so. You don't need any commercial tools: MinGW is probably sufficient. Build it once and you probably won't even need to recompile it ever again. Heck, if there isn't already a sourceforge project for what you describe, somebody should start one. However, this is definitely getting quite off-topic for the py2exe list. - Daniel. Geoff Bache wrote: > Thomas Heller wrote: >> Geoff Bache schrieb: >> >>>>> However, as the application as a whole requires Python to be >>>>> installed anyway it feels a bit odd to be distributing things copied >>>>> directly from the python distribution. Is there some way to tell >>>>> py2exe not to do that and create an executable that can automatically >>>>> find a python distribution from the registry and use the files from >>>>> that? >>>>> >>>>> >>>> I believe that setuptools (when creating eggs?) does create small >>>> executables for the scripts, so this may be a better way for you. >>>> >>>> >>> Thanks. It now occurs to me that perhaps all I need is a Windows batch >>> file that >>> does something like >>> >>> python myscript.py $* >>> >>> except I can't figure out how to do the UNIX "$*" on Windows. Any tips? >>> >> python myscript.py %* >> >> It requires that python.exe is on the PATH; the following might also work >> since .py files are associated with python.exe: >> >> myscript.py %* >> > > Thanks for the tips. That seems to work, as far as it goes, but it seems > I did need a .exe file after all... > otherwise it only works when the program is started via the shell... > > If I create myscript.bat and from a python prompt run > "subprocess.call(["myscript"])" > this fails. With shell=True it works. However if I have myscript.exe > instead it works with or > without the shell... So now I need to either compile the .bat file > (which seems like it requires commercial > tools, grrr) or figure out setuptools. Or is there some other way to do > this? > > (I'm basically trying to replicate the #!/usr/bin/env python syntax from > UNIX, which works with or without > the shell being explicitly used on startup) > > Regards, > Geoff > > > > > > ------------------------------------------------------------------------- > Check out the new SourceForge.net Marketplace. > It's the best place to buy or sell services for > just about anything Open Source. > http://sourceforge.net/services/buy/index.php |
From: Daniel P. <da...@pr...> - 2008-06-12 04:15:12
Attachments:
stub.zip.bin
|
For the record (I know it's offtopic, but...) here's a program that does exactly what your batch file does, and has the same limitations: specifically, it requires python.exe to be in the path. It's all of 22 lines of C, which is mostly some fiddling with arguments and error checking. I've built an executable with MSVC8, but you can compile it with GCC or anything else -- it's as vanilla as C gets. I'm posting to the list in the hope this may help someone else in the future... (The attachment is a zip file containing C source, an executable, and a Python test script. I've renamed to stub.zip.bin to get past the SourceForge filter.) - Daniel. Daniel Pryden wrote: > Just curious: if you're going to want to invoke it from a Python > process anyway (using subprocess.Popen or friends) then why not make > your Python program notice that it's trying to launch a Python script > and do an execfile instead? Or even parse the command line (I'm > presuming you want to mix and match Python scripts and other > executables) and look at the file extension: .exe and .com executed > directly, .bat and .cmd get executed through the shell, .py through > execfile or spawn a new Python executable, etc. > > Alternatively, it seems like a simple programming job in C to write a > small stub that finds the Python environment via the registry and > invokes it. (I know of several comparable launcher stubs for Java: > winrun4j.sf.net and javaservice.objectweb.org come immediately to > mind.) You could write a simple launcher stub in about 10-20 lines of > C# but I don't think you want the .NET dependency. Straight Win32 C > is a bit more complex but not impossibly so. You don't need any > commercial tools: MinGW is probably sufficient. Build it once and you > probably won't even need to recompile it ever again. Heck, if there > isn't already a sourceforge project for what you describe, somebody > should start one. > > However, this is definitely getting quite off-topic for the py2exe list. > > - Daniel. > > Geoff Bache wrote: >> Thomas Heller wrote: >>> Geoff Bache schrieb: >>> >>>>>> However, as the application as a whole requires Python to be >>>>>> installed anyway it feels a bit odd to be distributing things copied >>>>>> directly from the python distribution. Is there some way to tell >>>>>> py2exe not to do that and create an executable that can >>>>>> automatically >>>>>> find a python distribution from the registry and use the files from >>>>>> that? >>>>>> >>>>> I believe that setuptools (when creating eggs?) does create small >>>>> executables for the scripts, so this may be a better way for you. >>>>> >>>> Thanks. It now occurs to me that perhaps all I need is a Windows >>>> batch file that >>>> does something like >>>> >>>> python myscript.py $* >>>> >>>> except I can't figure out how to do the UNIX "$*" on Windows. Any >>>> tips? >>>> >>> python myscript.py %* >>> >>> It requires that python.exe is on the PATH; the following might also >>> work >>> since .py files are associated with python.exe: >>> >>> myscript.py %* >>> >> >> Thanks for the tips. That seems to work, as far as it goes, but it >> seems I did need a .exe file after all... >> otherwise it only works when the program is started via the shell... >> >> If I create myscript.bat and from a python prompt run >> "subprocess.call(["myscript"])" >> this fails. With shell=True it works. However if I have myscript.exe >> instead it works with or >> without the shell... So now I need to either compile the .bat file >> (which seems like it requires commercial >> tools, grrr) or figure out setuptools. Or is there some other way to >> do this? >> >> (I'm basically trying to replicate the #!/usr/bin/env python syntax >> from UNIX, which works with or without >> the shell being explicitly used on startup) >> >> Regards, >> Geoff >> >> >> >> >> >> ------------------------------------------------------------------------- >> >> Check out the new SourceForge.net Marketplace. >> It's the best place to buy or sell services for >> just about anything Open Source. >> http://sourceforge.net/services/buy/index.php > |