Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Python > Python 2.4, distutils, and pure python packages

Reply
Thread Tools

Python 2.4, distutils, and pure python packages

 
 
Fuzzyman
Guest
Posts: n/a
 
      03-10-2005
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

 
Reply With Quote
 
 
 
 
Thomas Heller
Guest
Posts: n/a
 
      03-10-2005
[CC to python-dev]
"Fuzzyman" <(E-Mail Removed)> 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
 
Reply With Quote
 
 
 
 
=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=
Guest
Posts: n/a
 
      03-11-2005
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
 
Reply With Quote
 
Fuzzyman
Guest
Posts: n/a
 
      03-11-2005

Thomas Heller wrote:
> [CC to python-dev]
> "Fuzzyman" <(E-Mail Removed)> 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

 
Reply With Quote
 
Thomas Heller
Guest
Posts: n/a
 
      03-11-2005
"Martin v. L÷wis" <(E-Mail Removed)> 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
 
Reply With Quote
 
=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=
Guest
Posts: n/a
 
      03-12-2005
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
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Python Packages : A loomingproblem? packages might no longer work? (well not on your platform or python version anyway) David Lyon Python 19 04-23-2009 11:10 PM
Pure space directly inside div ignored, but pure space directlyinside span honored liketofindoutwhy@gmail.com HTML 4 03-29-2008 06:06 PM
Pure functions still pure after definition Todd Aspeotis C++ 3 05-30-2005 03:53 AM
Do the javax.imageio packages replace packages in com.sun.image? Paul Smith Java 0 11-18-2003 02:58 PM



Advertisments