At 09:54 AM 1/13/2011 +0200, cool-RR wrote:
On Thu, Jan 13, 2011 at 2:25 AM, P.J. Eby <mailto:pje@telecommunity.compje@telecommunity.com> wrote: At 09:31 PM 1/12/2011 +0200, cool-RR wrote: Hi guys,
I made a release of my project today, and now I see there's something wrong with it.
When you install it on Windows using the windows binaries (that I made with `bdist_msi` under Python 2.7), the .exe scripts in the "Scripts" folder don't work. When you launch them, nothing happens. You can launch the associated *-script.pyw files and those *do* work.
I investigated a little and possibly I figured it out. The shebang line says "#!c:\Python27\pythonw.exe". This is the interpreter with which I *created* the binaries. But why should it be the interpreter with which the *user* works? The user could have "c:\Python26\pythonw.exe" as his interpreter or "c:\Programs\Python25\pythonw.exe" or "g:\Pypy\pypy.exe" as his interpreter.
I tried editing the shebang line with notepad, and this caused the exe files to start working! (Of course this is not a real solution, I can't ask my users to do that.)
Is this a bug in distribute?
It's a limitation of setuptools+bdist_msi - when you build a bdist_wininst, setuptools writes a generic #! line, but when you build a bdist_msi, it doesn't realize you're building a distribution.
So which project exactly is responsible for this limitation? Distribute?
Setuptools.
Do you think there's a good reason not to have the MSI put the path to python.exe itself into the shebang upon installation?
I don't know how to have bdist_msi do that. Do you?
As a quick workaround, you could try setting sys.executable to 'pythonw.exe' in your setup.py, *before* setuptools is imported, then build the .msi.
I'd be reluctant to do that, since many users don't have the Python folder on their PATH, so it won't work for them at all.
That's not how it works. When the #! line doesn't contain an absolute path, the .exe stub looks in the parent directory relative to where the script was installed. So, as long as the .exe and .pyw are in an immediate subdirectory of the Python directory (usually Scripts), it will work correctly.