Python 2.4, distutils, and pure python packages

F

Fuzzyman

Python 2.4 is built with Microsoft Visiual C++ 7. This means that it
uses msvcr7.dll, which *isn't* a standard part of the windows operating
system. This means that if you build a windows installer using
distutils - it *requires* msvcr7.dll in order to run. This is true even
if your package is a pure python package. This means that when someone
tries to use a windows installer created with Python 2.4, on a machine
with only python 2.3 - it will fail.

It's likely that nothing can be done about this (although for a pure
python package there's no reason not to use the 'source distribution'
and the setup.py). It does mean that I have to build my windows
installer on a machine with python 2.3.

Regards,

Fuzzy
http://www.voidspace.org.uk/python/index.shtml
 
T

Thomas Heller

[CC to python-dev]
Fuzzyman said:
Python 2.4 is built with Microsoft Visiual C++ 7. This means that it
uses msvcr7.dll, which *isn't* a standard part of the windows operating
system.

Nitpicking - it's MSVC 7.1, aka MS Visual Studio .NET 2003, and it's
msvcr71.dll.
This means that if you build a windows installer using
distutils - it *requires* msvcr7.dll in order to run. This is true even
if your package is a pure python package. This means that when someone
tries to use a windows installer created with Python 2.4, on a machine
with only python 2.3 - it will fail.
Bummer.

It's likely that nothing can be done about this (although for a pure
python package there's no reason not to use the 'source distribution'
and the setup.py). It does mean that I have to build my windows
installer on a machine with python 2.3.

There's a workaround, although ugly.

bdist_wininst has a --target-version flag which allows to build an
installer for another Python version. It works both for pure Python
packages, and for (how are they called? non-pure?) packages containing
compiled extensions. The 2.4 distutils package has all that is needed
to create a installer running with python 2.3 or maybe even 2.2 (which
uses msvcrt.dll instead of msvcr71.dll). The result, of course, is that
the installer can only install for the version that you specified at
build time.

Because distutils cannot cross-compile extensions for other versions,
you must have build extensions (if there are any to include) with the
other Python version before - distutils will simply pick up the
extensions it finds in build subdirectories for the other version.

Anyway, whether you have extensions or not, you must also specify the
--skip-build command line flag, distutils will complain if you don't.
So, for a pure distribution you would typically run these commands to
build separate installers for 2.3 and 2.4:

\python24\python setup.py --skip-build --target-version 2.3 bdist_wininst
\python24\python setup.py --skip-build --target-version 2.4 bdist_wininst

and for non-pure packages you must compile with each version before
building the installer (if you want for some reason to use python 2.4
to build the installer for 2.3):

\python24\python setup.py build_ext
\python23\python setup.py build_ext

\python24\python setup.py --skip-build --target-version 2.3 bdist_wininst
\python24\python setup.py --skip-build --target-version 2.4 bdist_wininst

OTOH, it's no problem to install both python 2.3 and python 2.4 in
separate directories on the same machine and always make native builds.

--

To make this story even more complete, there have been also other
bugs caused by the different runtime dlls used in 2.3 and 2.4, most
only showing when you use the --install-script option. The installer
was using msvcrt.dll and msvcr71.dll at the same time, which led to
crashes when the install script was started - the PythonCard installer
suffered from that, at least. The bug only occurred with pure python
distributions, because then the dll problem occurred.

The bug is solved in Python 2.3.5, and also in the 2.4.1 release which
will be out soon, with one exception: if the install-script prints
something the output will be lost instead of displayed on the last
screen. At least that's better than crashing the process.


Thomas
 
?

=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=

Thomas said:


I wonder whether it would be better to continue linking wininst.exe with
mscvrt40.dll, and use that regardless of the version used to build Python.

Alternatively, we could try to get rid of the C library altogether for
wininst.exe. For install.c, this should be possible: it primarily uses
*printf, which can be replaced with FormatMessage. The challenge, of
course, is zlib. This could be replaced with lz32, but I doubt this
would improve anything. Alternatively, we could load zlib.pyd from the
target system, but that would be tedious, I guess. OTOH, it might to
replace extract.c largely with Python source code, and run this in
an interpreter...

Regards,
Martin
 
F

Fuzzyman

Thomas said:
[CC to python-dev]
Fuzzyman said:
Python 2.4 is built with Microsoft Visiual C++ 7. This means that it
uses msvcr7.dll, which *isn't* a standard part of the windows operating
system.

Nitpicking - it's MSVC 7.1, aka MS Visual Studio .NET 2003, and it's
msvcr71.dll.

Sorry - my mistake !
There's a workaround, although ugly.

[snip..] Yuck ! Distributing different versions of a pure python
package :) As I maintain a 2.3 machine as well, it's not too bad for
me. I posted this mainly for the reference of others.

Thanks for your reply Thomas.

Regards,

Fuzzyman
http://www.voidspace.org.uk/python/index.shtml
 
T

Thomas Heller

Martin v. Löwis said:
I wonder whether it would be better to continue linking wininst.exe with
mscvrt40.dll, and use that regardless of the version used to build Python.

Alternatively, we could try to get rid of the C library altogether for
wininst.exe. For install.c, this should be possible: it primarily uses
*printf, which can be replaced with FormatMessage. The challenge, of
course, is zlib. This could be replaced with lz32, but I doubt this
would improve anything. Alternatively, we could load zlib.pyd from the
target system, but that would be tedious, I guess. OTOH, it might to
replace extract.c largely with Python source code, and run this in
an interpreter...

I had something similar in my mind for quite some time. zlib.pyd would be
used automatically if the extraction is done in Python code - when
bdist_wininst was written, Python didn't have the zipfile module.

It would be for 2.5, anyway, and I have hoped that bdist_wininst would
be replaced by bdist_msi then ;-). What are your plans for that?

Although I'm wondering if it would be possible to run bdist_msi on linux
systems for pure Python distributions - some people are doing that with
bdist_wininst afaik.

Thomas
 
?

=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=

Thomas said:
It would be for 2.5, anyway, and I have hoped that bdist_wininst would
be replaced by bdist_msi then ;-). What are your plans for that?

I still hope to write one by for 2.5.

One issue is that you cannot have multiple installations of an MSI
package. So if you want to support different Python installations
on the same machine, you have to clone the MSI file, and change the
product code - or provide multiple MSI files in the first place.

So I guess bdist_wininst would continue to provide a value to
certain users, as you can have as many installations of it as
you want (but then, it doesn't allow to select a target directory,
so you can have only as many installations as you find in the
registry).

Regards,
Martin
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,744
Messages
2,569,484
Members
44,903
Latest member
orderPeak8CBDGummies

Latest Threads

Top