F
Fernando Perez
Hi all,
I am seeking advice/help from those with more win32 experience than myself. I
am trying to build a proper win32 installer for IPython, after a user did most
of the hard work. For the most part, it's working very well, but I am running
into a nasty problem, which took me a few hours to finally understand. This
smells to me like a python bug, but I could be wrong. Much googling didn't
turn up anything relevant.
Here is a brief summary: if the installer file is run from a windows drive which
is different from the one where python resides (and hence where ipython will
end up), the installer segfaults. No traceback, nothing, just a segfault
(well, one of those Windows dialogs asking me to send a binary traceback to
Redmond, but not a proper Python traceback).
The win32 laptop where I'm testing, for example, has user stuff in the D: drive,
and Python installed in C:\Python23. I was running the installer from D:\Temp,
and getting this segfault. If I run it from C:\Temp, it works perfectly.
I have put the installer here, in case someone else is willing to test this on a
different machine:
http://amath.colorado.edu/faculty/fperez/tmp/ipython-0.6.9.win32.exe
I have narrowed down to a single os.chdir() call in the post-install script.
The code is simply:
# Lookup path to common startmenu ...
d = get_special_folder_path('CSIDL_COMMON_PROGRAMS') + r'\IPython'
# Create IPython entry ...
if not os.path.isdir(d):
os.mkdir(d)
directory_created(d)
# XXX - The binary installer segfaults here if it was being run from a
# different drive than it is trying to change to. In my case, I have
# everything in D:, but Python lives in C:, so the chdir() call is going
# from D: to C:, and this is crashing things.
print "Current dir:",os.getcwd() # dbg
print "Going to :",d # dbg
os.chdir(d)
By forcing a return before the chdir() call, I was able to see that when the
source/destination are both on C:, it's all OK, but when the source is in D:
and the destination in C:, I get the crash.
This is really frustrating, since I'd like to be able to stop distributing .zip
sources to Windows users, and would like to be able to provide a proper
installer/deinstaller. But having this thing crash if two drives are involved
is just not acceptable.
Any help from the win32 gurus out there would be much appreciated. For
reference, the binary installer linked above was created on a Fedora3 box
running pyhton 2.3.4, with the command line:
../setup.py bdist_wininst --install-script=ipython_win_post_install.py
Cheers,
f
I am seeking advice/help from those with more win32 experience than myself. I
am trying to build a proper win32 installer for IPython, after a user did most
of the hard work. For the most part, it's working very well, but I am running
into a nasty problem, which took me a few hours to finally understand. This
smells to me like a python bug, but I could be wrong. Much googling didn't
turn up anything relevant.
Here is a brief summary: if the installer file is run from a windows drive which
is different from the one where python resides (and hence where ipython will
end up), the installer segfaults. No traceback, nothing, just a segfault
(well, one of those Windows dialogs asking me to send a binary traceback to
Redmond, but not a proper Python traceback).
The win32 laptop where I'm testing, for example, has user stuff in the D: drive,
and Python installed in C:\Python23. I was running the installer from D:\Temp,
and getting this segfault. If I run it from C:\Temp, it works perfectly.
I have put the installer here, in case someone else is willing to test this on a
different machine:
http://amath.colorado.edu/faculty/fperez/tmp/ipython-0.6.9.win32.exe
I have narrowed down to a single os.chdir() call in the post-install script.
The code is simply:
# Lookup path to common startmenu ...
d = get_special_folder_path('CSIDL_COMMON_PROGRAMS') + r'\IPython'
# Create IPython entry ...
if not os.path.isdir(d):
os.mkdir(d)
directory_created(d)
# XXX - The binary installer segfaults here if it was being run from a
# different drive than it is trying to change to. In my case, I have
# everything in D:, but Python lives in C:, so the chdir() call is going
# from D: to C:, and this is crashing things.
print "Current dir:",os.getcwd() # dbg
print "Going to :",d # dbg
os.chdir(d)
By forcing a return before the chdir() call, I was able to see that when the
source/destination are both on C:, it's all OK, but when the source is in D:
and the destination in C:, I get the crash.
This is really frustrating, since I'd like to be able to stop distributing .zip
sources to Windows users, and would like to be able to provide a proper
installer/deinstaller. But having this thing crash if two drives are involved
is just not acceptable.
Any help from the win32 gurus out there would be much appreciated. For
reference, the binary installer linked above was created on a Fedora3 box
running pyhton 2.3.4, with the command line:
../setup.py bdist_wininst --install-script=ipython_win_post_install.py
Cheers,
f