[wxPython] Installation with Gordon's installer and or py2exe

Hi,

I have a fairly complicated application, using wxpython heavily, that
works well from a script. I have been trying to freeze it with
Gordon's installer (which I have used before but with python1.5),
The problem I run into with python20 is not with wxpython but with
certain cmodules that come with python itself, namely cPickle,
rotor and time. The installer produces an exe file, but when I try to
run it I simply get an error message saying that it cannot load the
first of these modules (they are all specified as modules to be
imported in my own scripts). This seems very odd, because they
are standard modules. If I leave import statements for them out,
then the installer produces an exe file which will run, until
something is called which depends on these modules. The
Builder.log does not show anything problematic, and nor does
screen output, even with the debugger switch.

On the other hand, py2exe works fine, giving me an exe file that
works for me personally. However I have found that the exe file that
it produces fails to recognise associated dlls if it is run from a
different drive mapping on our network even though all the dlls are
placed in the directory from which it is run (it will work fine from
anywhere on a local disk, even of a PC with no python installation
on it). This makes the py2exe installation unsatisfactory for
network use (and my application is designed to be used on a
network).

I would very much appreciate suggestions as to how I might solve
my problems with installation..

Yours,
Roger Young

Has anybody got an idea of

Roger Young,
Philosophy Department,
University of Dundee
r.a.young@dundee.ac.uk
tel 01382 344539

···

_______________________________________________
wxPython-users mailing list
wxPython-users@lists.sourceforge.net
http://lists.sourceforge.net/lists/listinfo/wxpython-users

I have a fairly complicated application, using wxpython heavily, that
works well from a script. I have been trying to freeze it with
Gordon's installer (which I have used before but with python1.5),
The problem I run into with python20 is not with wxpython but with
certain cmodules that come with python itself, namely cPickle,
rotor and time. The installer produces an exe file, but when I try to
run it I simply get an error message saying that it cannot load the
first of these modules (they are all specified as modules to be
imported in my own scripts). This seems very odd, because they
are standard modules.

You need to add this:

    sys.path.append(imputil.BuiltinImporter())

to the Installer in support/archive_rt.py. I put it right after the imports at the top.

On the other hand, py2exe works fine, giving me an exe file that
works for me personally. However I have found that the exe file that
it produces fails to recognise associated dlls if it is run from a
different drive mapping on our network even though all the dlls are
placed in the directory from which it is run (it will work fine from
anywhere on a local disk, even of a PC with no python installation
on it). This makes the py2exe installation unsatisfactory for
network use (and my application is designed to be used on a
network).

Have you tried py2exe 0.20? I was just released this morning. It does a better job of rounding up the right DLLs, even better than Gordon's Installer I think. One thing I have noticed however is that system DLLs, especially MSVC*.dll, must be installed into the system directory, and should be version checked by the installer. If they are left in the app directory the app fails immediately with ImportError when run on a machine different than the development machine. In my InnoSetup script I do it like this (long lines wrapped):

Source: "MSVCRT.dll"; DestDir: "{sys}"; CopyMode: onlyifdoesntexist; Flags: sharedfile uninsneveruninstall
Source: "MSVCIRT.dll"; DestDir: "{sys}"; CopyMode: onlyifdoesntexist; Flags: sharedfile uninsneveruninstall
Source: "DCIMAN32.dll"; DestDir: "{sys}"; CopyMode: onlyifdoesntexist; Flags: sharedfile uninsneveruninstall
Source: "DDRAW.dll"; DestDir: "{sys}"; CopyMode: onlyifdoesntexist; Flags: sharedfile uninsneveruninstall
Source: "GLU32.dll"; DestDir: "{sys}"; CopyMode: onlyifdoesntexist; Flags: sharedfile uninsneveruninstall
Source: "OPENGL32.dll"; DestDir: "{sys}"; CopyMode: onlyifdoesntexist; Flags: sharedfile uninsneveruninstall

although I'm not sure "uninsneveruninstall" should be there but it was in an example I was looking at...

···

--
Robin Dunn
Software Craftsman
robin@AllDunn.com Java give you jitters?
http://wxPython.org Relax with wxPython!

_______________________________________________
wxPython-users mailing list
wxPython-users@lists.sourceforge.net
http://lists.sourceforge.net/lists/listinfo/wxpython-users

Dear all,

First, I would like to thank Robin for his very prompt and helpful
reply to my message last week about problems I had with Gordon's
installer and py2exe when I used them to produce an installation
version of an application I had. His advice was most valuable. Part
of what he said was:

Have you tried py2exe 0.20? I was just released this morning. It
does a better job of rounding up the right DLLs, even better than
Gordon's Installer I think. One thing I have noticed however is
that system DLLs, especially MSVC*.dll, must be installed into the
system directory, and should be version checked by the installer.
If they are left in the app directory the app fails immediately
with ImportError when run on a machine different than the
development machine.

After his email, I did try the new version of py2exe and I found it an
improvement on the earlier one and also better, at least for my
purposes, than Gordon's installer. However, I need to raise a
question about the MSVC*.dll files. My university's central
information technology service have informed me that the dll's I am
using (as a result of installing python 2 and libraries including
wxpython 2.2) are ones that come from Windows 98 millenium
edition or Windows 2000. What my university runs is Windows NT
4. When we overwrote the NT 4 MSVC*.dll files with their Python
provided equivalents, on three trial workstations, they appeared to
work satisfactorily, for those applications we tried. On this basis,
our ITS service has installed the new files on the workstation in the
lecture hall I use. However, my intention was to distribute my
application to my students, and thus the issue is whether it is safe
to overwrite original NT4 files on hundreds of workstations across
the campus. So far, the ITS service here have been very helpful, but
they have written to Microsoft to ask them whether they would
advise that the substitution is safe (and have not yet had a reply).
They have also asked me to write to python/wxpython developers
to ask (a) for information about any known problems with replacing
these files and (b) whether it is really necessary to use these
particular MSVC*.dll files for current versions of python and the
relevant libraries, or would it be possible to compile python (etc)
from source and use earlier versions of the MSVC*.dll files?

The installation logs all indicate that Python 2.0 (BeOpen) the
Win32 extension, and wxpython all overwrite the MSVC*.dll files. I
presume that they all install the same version of these files, but the
install logs do not give version information, and I have not done an
incremental check myself on what is installed. Perhaps, I should
add that in the student labs we run NT4 with service pack 3, but
my department is up to service pack 5 (I have not checked for
variations in MSVC*.dll files)

So, it is possible I should address my questions to some other list,
but I thought I would start by putting them to the wxpython list,
because I have found it so helpful.

Yours,
Roger Young

Roger Young,
Philosophy Department,
University of Dundee
r.a.young@dundee.ac.uk
tel 01382 344539

···

From: "Robin Dunn" <robin@alldunn.com>

_______________________________________________
wxPython-users mailing list
wxPython-users@lists.sourceforge.net
http://lists.sourceforge.net/lists/listinfo/wxpython-users

Roger Young wrote:

After his email, I did try the new version of py2exe and I found it an
improvement on the earlier one and also better, at least for my
purposes, than Gordon's installer. However, I need to raise a
question about the MSVC*.dll files. My university's central
information technology service have informed me that the dll's I am
using (as a result of installing python 2 and libraries including
wxpython 2.2) are ones that come from Windows 98 millenium
edition or Windows 2000. What my university runs is Windows NT
4. When we overwrote the NT 4 MSVC*.dll files with their Python
provided equivalents, on three trial workstations, they appeared to
work satisfactorily, for those applications we tried. On this basis,
our ITS service has installed the new files on the workstation in the
lecture hall I use. However, my intention was to distribute my
application to my students, and thus the issue is whether it is safe
to overwrite original NT4 files on hundreds of workstations across
the campus. So far, the ITS service here have been very helpful, but
they have written to Microsoft to ask them whether they would
advise that the substitution is safe (and have not yet had a reply).

I don't know whether or not this installer replaces ComCat.DLL, but
don't overwrite that one. The Win 98 version is 5.01, the NT version is
4.71. The Win 98 version will cause problems for COM under Windows
NT. This shows that one cannot decide what to replace based only on
name and version number.

Al

···

_______________________________________________
wxPython-users mailing list
wxPython-users@lists.sourceforge.net
http://lists.sourceforge.net/lists/listinfo/wxpython-users

However, I need to raise a
question about the MSVC*.dll files. My university's central
information technology service have informed me that the dll's I am
using (as a result of installing python 2 and libraries including
wxpython 2.2) are ones that come from Windows 98 millenium
edition or Windows 2000.

Actually, they are independent of the version of the OS and are actually the
ones that come with VC++ 6 SP 3. Since this is probably the compiler used
to build Win2k and WinME then that is why they have the same version.

my intention was to distribute my
application to my students, and thus the issue is whether it is safe
to overwrite original NT4 files on hundreds of workstations across
the campus.

As long as the installer program does a version check on the files to be
sure it doesn't replace newer versions, and also does whatever it takes to
install them as shared files so the uninstaller wont remove them if other
apps still need them.

So far, the ITS service here have been very helpful, but
they have written to Microsoft to ask them whether they would
advise that the substitution is safe (and have not yet had a reply).

Probably every app you install, and surely every MS app, does the same
thing.

They have also asked me to write to python/wxpython developers
to ask (a) for information about any known problems with replacing
these files and

As long as the version checks and the mark as shared are done, then no known
problems.

(b) whether it is really necessary to use these
particular MSVC*.dll files for current versions of python and the
relevant libraries,

Some systems don't have MSVCIRT.dll installed, and it does need to have the
same version of MSVCRT.dll. If both are already there then you may be
alright.

or would it be possible to compile python (etc)
from source and use earlier versions of the MSVC*.dll files?

Yes, but you'll probably have to use whatever version of the DLLs comes with
the compiler you use.

So, it is possible I should address my questions to some other list,
but I thought I would start by putting them to the wxpython list,
because I have found it so helpful.

Hope this helps.

I should probably add a disclaimer that I have no athoritative source for
the above information. It is gleaned from my experience and educated
guesses and information from others.

···

--
Robin Dunn
Software Craftsman
robin@AllDunn.com Java give you jitters?
http://wxPython.org Relax with wxPython!

_______________________________________________
wxPython-users mailing list
wxPython-users@lists.sourceforge.net
http://lists.sourceforge.net/lists/listinfo/wxpython-users

Robin Dunn wrote:

I should probably add a disclaimer that I have no athoritative source
for the above information. It is gleaned from my experience and
educated guesses and information from others.

When I had the problem with ComCat.DLL v5 not working under NT while
v4.71 is the correct version for Windows NT, I got the idea that it was
an error for an installer to replace this DLL. Certain DLL's, and I'm
not sure which ones, are considered part of Windows, and these should
be replaced only by the Windows service packs and patches from MS, never
by the installer for an application, regardless of version numbers.

MS has created a jungle, and that's evidently how they want to deal with
it. In this age of cheap disk, the best solution is probably separate
copies of DLL's for each app, but this leads us to want the search for
DLL's to start in the directory of the caller, which is what Windows
does but not Python, IIRC.

Al

···

_______________________________________________
wxPython-users mailing list
wxPython-users@lists.sourceforge.net
http://lists.sourceforge.net/lists/listinfo/wxpython-users

When I had the problem with ComCat.DLL v5 not working under NT while
v4.71 is the correct version for Windows NT, I got the idea that it was
an error for an installer to replace this DLL. Certain DLL's, and I'm
not sure which ones, are considered part of Windows, and these should
be replaced only by the Windows service packs and patches from MS, never
by the installer for an application, regardless of version numbers.

Yes, I agree. But I think the MSVC*.dll files are in kind of a grey area.
They are considered part of VC++'s redistributable runtime but MSVCRT.dll at
least is treated specially like a system DLL.

MS has created a jungle, and that's evidently how they want to deal with
it. In this age of cheap disk, the best solution is probably separate
copies of DLL's for each app,

Which is exactly what WinME does automatically. IIRC, every time an app
installs a DLL to the system directory that is a different version than one
already there then a copy is made and each app uses the one it installed.
Seems like a stupid waste of disk and memory to me, but apparently is the
only way that MS figured out how to get out of the hole they dug for
themselves...

but this leads us to want the search for
DLL's to start in the directory of the caller, which is what Windows
does but not Python, IIRC.

It's the directory of the .exe, or .pyd in our case, except for those
special system DLLs which must be loaded from the windows system directory.

[ Same disclaimer applies... ]

···

--
Robin Dunn
Software Craftsman
robin@AllDunn.com Java give you jitters?
http://wxPython.org Relax with wxPython!

_______________________________________________
wxPython-users mailing list
wxPython-users@lists.sourceforge.net
http://lists.sourceforge.net/lists/listinfo/wxpython-users