Python 2.4, distutils, and pure python packages

Discussion in 'Python' started by Fuzzyman, Mar 10, 2005.

  1. Fuzzyman

    Fuzzyman Guest

    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
    Fuzzyman, Mar 10, 2005
    #1
    1. Advertising

  2. [CC to python-dev]
    "Fuzzyman" <> 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
    Thomas Heller, Mar 10, 2005
    #2
    1. Advertising

  3. 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
    =?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=, Mar 11, 2005
    #3
  4. Fuzzyman

    Fuzzyman Guest

    Thomas Heller wrote:
    > [CC to python-dev]
    > "Fuzzyman" <> 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
    Fuzzyman, Mar 11, 2005
    #4
  5. "Martin v. Löwis" <> 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
    Thomas Heller, Mar 11, 2005
    #5
  6. 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
    =?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=, Mar 12, 2005
    #6
    1. Advertising

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

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Todd Aspeotis
    Replies:
    3
    Views:
    458
    Kanenas
    May 30, 2005
  2. Replies:
    4
    Views:
    781
    Ben C
    Mar 29, 2008
  3. Paul Hemans
    Replies:
    4
    Views:
    274
    Paul Hemans
    May 20, 2009
  4. Jeremy
    Replies:
    1
    Views:
    289
    Gabriel Genellina
    Jan 24, 2010
  5. XLiIV
    Replies:
    1
    Views:
    112
    Stefan Behnel
    Feb 25, 2012
Loading...

Share This Page