473,320 Members | 1,988 Online
Bytes | Software Development & Data Engineering Community
Post Job

Home Posts Topics Members FAQ

Join Bytes to post your question to a community of 473,320 software developers and data experts.

Python 2.4, distutils, and pure python packages

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

Jul 18 '05 #1
5 2633
[CC to python-dev]
"Fuzzyman" <fu******@gmail.com> writes:
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
Jul 18 '05 #2
Thomas Heller wrote:
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.

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
Jul 18 '05 #3

Thomas Heller wrote:
[CC to python-dev]
"Fuzzyman" <fu******@gmail.com> writes:
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 !
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.


[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

Jul 18 '05 #4
"Martin v. Löwis" <ma****@v.loewis.de> writes:
Thomas Heller wrote:
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.

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
Jul 18 '05 #5
Thomas Heller wrote:
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
Jul 18 '05 #6

This thread has been closed and replies have been disabled. Please start a new discussion.

Similar topics

3
by: Matt Shomphe | last post by:
Are there any guidelines for packaging a pure python module? Specifically, say I have a set of 10 functions, all of varying behaviors (no unifying theme to bind them together into clear subsets),...
29
by: Stephen Ferg | last post by:
I am a very satisfied user of Python and have been for number of years. I would never willing use another language. I wish all good things for Python, and that moves me to express some thoughts...
8
by: Georg Brandl | last post by:
Hello c.l.py, what features would you expect of a Python package manager, similar to CPAN or rubygems? I am currently planning to write such a thing, at first privately for myself, and if...
15
by: kyosohma | last post by:
Hi, I am trying to get a small group of volunteers together to create Windows binaries for any Python extension developer that needs them, much like the package/extension builders who volunteer...
9
by: pythonewbie | last post by:
Hi all, I am newbie in Python, my wish would be to create python applications for both Linux/Win32. I am stucked on creating a function to get the Python install directory (and site-packages...
4
by: Alia Khouri | last post by:
Can we open up the discussion here about how to improve setuptools which has become the de facto standard for distributing / installing python software. I've been playing around with ruby's gems...
0
isladogs
by: isladogs | last post by:
The next Access Europe meeting will be on Wednesday 6 Mar 2024 starting at 18:00 UK time (6PM UTC) and finishing at about 19:15 (7.15PM). In this month's session, we are pleased to welcome back...
0
by: Vimpel783 | last post by:
Hello! Guys, I found this code on the Internet, but I need to modify it a little. It works well, the problem is this: Data is sent from only one cell, in this case B5, but it is necessary that data...
0
by: jfyes | last post by:
As a hardware engineer, after seeing that CEIWEI recently released a new tool for Modbus RTU Over TCP/UDP filtering and monitoring, I actively went to its official website to take a look. It turned...
0
by: ArrayDB | last post by:
The error message I've encountered is; ERROR:root:Error generating model response: exception: access violation writing 0x0000000000005140, which seems to be indicative of an access violation...
0
by: CloudSolutions | last post by:
Introduction: For many beginners and individual users, requiring a credit card and email registration may pose a barrier when starting to use cloud servers. However, some cloud server providers now...
0
by: Defcon1945 | last post by:
I'm trying to learn Python using Pycharm but import shutil doesn't work
1
by: Shællîpôpï 09 | last post by:
If u are using a keypad phone, how do u turn on JavaScript, to access features like WhatsApp, Facebook, Instagram....
0
by: Faith0G | last post by:
I am starting a new it consulting business and it's been a while since I setup a new website. Is wordpress still the best web based software for hosting a 5 page website? The webpages will be...
0
isladogs
by: isladogs | last post by:
The next Access Europe User Group meeting will be on Wednesday 3 Apr 2024 starting at 18:00 UK time (6PM UTC+1) and finishing by 19:30 (7.30PM). In this session, we are pleased to welcome former...

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.