py2exe Problems...

Community matplotlib-users
1

I still get the TimeZone error...

I spent a little time looking at this this morning. I found that I
needed to explicitly put the utc timezone in my script that I was
freezing, it was not enough to include it in my includes list. Oddly,
this was not consistent. In the simple_plot_wxagg example, I had the
timezone info in my includes list only and it worked w/o incident. In
the simple_plot_gtk example, I needed to manually add

import pytz.zoneinfo.UTC

to my simple_plot.py script. Strange...

Also, what kinds of files should be in the includes list? For example,
in Michael's list, he includes

    "matplotlib._na_image",
    "matplotlib._na_transforms",
    "matplotlib._nc_image",
    "matplotlib._nc_transforms",

but not

    "matplotlib._image"
    "matplotlib._transforms"

The latter two are python files, the former extension code. Do you
typically need to manually point py2exe to the extension files?

Anyway, the wxagg and gtk examples in the updated
http://matplotlib.sourceforge.net/py2exe_examples.zip build and run on
my machine. They are a bit of a hack in that I don't really
understand why/how/when the includes work. If someone can rationalize
these scripts, improve them, extend them, whatever, send the updates
my way.

JDH

2

Hi John,

I took your zip file and changed the simple_plot_agg sample to just this and it looks like it works:

data = glob.glob(r'C:\Python24\share\matplotlib\*')
#data.append(r'C:\Enthon23\share\matplotlib\.matplotlibrc')

setup(console=["simple_plot.py"],
       data_files=[("matplotlibdata",data)],
       options = {"py2exe": {"compressed": 1,
                             # optimize may break pylab docstring handling
                             #"optimize": 2,
                             #"includes": includes,
                             #"excludes": excludes,
                             "packages": ["encodings", "pytz"],
                            }},
       )

Note that I use "packages" and NOT include, all the matplotlib and numeric stuff seems to get detected correctly by py2exe.

The excludes don't seem to make a difference, I think py2exe removes them now by itself.

Only error/warnings I get is that I did not include an .matplotlibrc file. Could you send me yours?

By doing this I found a few more oversights (wx to wx.) in backend, updated version is attached.

See you
Werner

John Hunter wrote:

backend_wx.py (67.6 KB)

···

"andrea" == andrea gavana <andrea_gavana@...517...> writes:

    > I still get the TimeZone error...

I spent a little time looking at this this morning. I found that I
needed to explicitly put the utc timezone in my script that I was
freezing, it was not enough to include it in my includes list. Oddly,
this was not consistent. In the simple_plot_wxagg example, I had the
timezone info in my includes list only and it worked w/o incident. In
the simple_plot_gtk example, I needed to manually add

import pytz.zoneinfo.UTC

to my simple_plot.py script. Strange...

Also, what kinds of files should be in the includes list? For example,
in Michael's list, he includes

    "matplotlib._na_image",
    "matplotlib._na_transforms",
    "matplotlib._nc_image",
    "matplotlib._nc_transforms",

but not

    "matplotlib._image"
    "matplotlib._transforms"

The latter two are python files, the former extension code. Do you
typically need to manually point py2exe to the extension files?

Anyway, the wxagg and gtk examples in the updated
http://matplotlib.sourceforge.net/py2exe_examples.zip build and run on
my machine. They are a bit of a hack in that I don't really
understand why/how/when the includes work. If someone can rationalize
these scripts, improve them, extend them, whatever, send the updates
my way.

JDH

-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click

3

Hi,

    > I still get the TimeZone error...

I spent a little time looking at this this morning. I found that I
needed to explicitly put the utc timezone in my script that I was
freezing, it was not enough to include it in my includes list. Oddly,
this was not consistent. In the simple_plot_wxagg example, I had the
timezone info in my includes list only and it worked w/o incident. In
the simple_plot_gtk example, I needed to manually add

import pytz.zoneinfo.UTC

to my simple_plot.py script. Strange...

For me I've found that I've needed to include every level of a given
module individually to get it working, e.g. 'pytz', 'pytz.timezone'
and 'pytz.timezone.UTC'. After that py2exe works for me.

This (to me) is an example of how stuff which dynamically imports
modules at runtime trips up stuff like py2exe (I believe the py.test
folks are losing a lot of hair over dynamic imports in their testing
magic too). What I think is happening here (and in encodings) is that
normal usage involves just importing the toplevel module in your app's
code, and at runtime you invoke a call which then goes and imports the
module supplying the code you need. So when py2exe analyses the code,
it doesn't see your runtime import and misses the relevant module.

Adding an explicit import in your app should be pretty much the same
as using a py2exe include, except that it introduces some overhead at
runtime. To handle every timezone your would have to import every
timezone in your app, whereas with py2exe's includes you just specify
what to stick in the zip and the app can import just the timezone it
needs at runtime. Theoretically anyway :slight_smile:

To add fun to the mix, any package which dynamically imports stuff at
runtime usually has to be careful to either be aware of how it lives
in a zip when frozen, or not to do anything dependant on it's file
path.

Also, what kinds of files should be in the includes list? For example,
in Michael's list, he includes

    "matplotlib._na_image",
    "matplotlib._na_transforms",
    "matplotlib._nc_image",
    "matplotlib._nc_transforms",

but not

    "matplotlib._image"
    "matplotlib._transforms"

The latter two are python files, the former extension code. Do you
typically need to manually point py2exe to the extension files?

I've found py2exe has given me difficulty when looking for extensions,
so my list of includes represents partially extensions I've found to
be missing in frozen apps when trying to run them and partially every
other extension I've come across for good measure (since I was doing a
build, crash, add missing extension loop, I decided to add them all).
Depending on how apps and modules handle imports, py2exe seems to be
able to pick up pure python stuff more easily than python extensions.

All this could be just a mix of my particular setup and the
applications I deal with, no two people's py2exe problems ever seem to
be the same :slight_smile:

All the problems centre around py2exe's module finding logic, every
problem I've encountered has been due to py2exe missing out on one or
two modules (in particular ones which do very dynamic imports at run
time as oppose to import time), so there is a lovely cargo cult feel
to my includes list, I decided the five minutes of adding all the
includes I might need from a given package was worth it, rather than
the repeated half hour of tracking down people's problems when running
the apps.

Anyway, the wxagg and gtk examples in the updated
http://matplotlib.sourceforge.net/py2exe_examples.zip build and run on
my machine. They are a bit of a hack in that I don't really
understand why/how/when the includes work. If someone can rationalize
these scripts, improve them, extend them, whatever, send the updates
my way.

I'll have a go with them and see how they fair under my esoteric
setup. I'm going to bet that I'll have problems no one else does :wink:

Michael

···

On Apr 11, 2005 6:02 PM, John Hunter <jdhunter@...4...> wrote:

4

Well, after looking at the examples you'll be pleased to hear they
cleared up a fundamental misunderstanding I had with py2exe's
configuration. You won't be so pleased to hear that they blew up
dramatically and in an interesting new way (for me) when I tried to
run the frozen exes :slight_smile:

I had been mixing up distutils' packages directive (which lists
packages in your source tree) and py2exe's 'packages' option (which
does what my lengthy includes do in one go with the package). Using
the packages directive leads to errors, 'packages' does what I
expected.

So you can pretty much ignore my includes, though I think my comments
about hand holding py2exe's module finding still stand.

Now, on to the problem:

C:\temp\py2exe\simple_plot_gtk\dist>date_demo.exe
Fatal Python error: Call to API function without first calling import_libnumarra
y() in Src\_convmodule.c

This application has requested the Runtime to terminate it in an unusual way.
Please contact the application's support team for more information.

If I add numarray to the packages list it works fine for me.

(I also had to copy in the lib and etc directories from my GTK install
to keep GTK+ happy, since it needs supporting files and libraries,
that's a pygtk/GTK+ specific thing.)

Even when I remove the pytz imports from the simple_plot_gtk scripts
py2exe doesn't seem to have any problems, the pytz package include
does the trick for me.

I've attached a diff showing the minor modifications I made.

The complete set of commands I used to build (under cygwin with
official python, not the cygwin python):

$ python.exe setup.py py2exe
$ cp -r /c/GTK/etc dist
$ cp -r /c/GTK/lib dist
$ ./dist/date_demo.exe

cheers,
  Michael

py2exe.diff (2.09 KB)

5

Hi Michael,

This is all I need:

Obviously the two first lines you need to adapt.

data = glob.glob(r'C:\Python24\share\matplotlib\*')
data.append(r'C:\Python24\share\matplotlib\.matplotlibrc')

setup(console=["simple_plot.py"],
       data_files=[("matplotlibdata",data)],
       options = {"py2exe": {"compressed": 1,
                             # optimize breaks pylab docstring handling
                             #"optimize": 2,
                             "packages": ["encodings", "pytz"],
                            }},
       )

Note that I use "packages" and NOT include, all the matplotlib and numeric stuff seems to get detected correctly by py2exe.

I am not even sure about encodings, but as I had problems with this before I just always put it there.

I see in your later post that you came to a similar conclusion.

See you
Werner

Michael Twomey wrote:

···

Hi,

On Apr 11, 2005 6:02 PM, John Hunter <jdhunter@...4...> wrote:

"andrea" == andrea gavana <andrea_gavana@...517...> writes:

   > I still get the TimeZone error...

I spent a little time looking at this this morning. I found that I
needed to explicitly put the utc timezone in my script that I was
freezing, it was not enough to include it in my includes list. Oddly,
this was not consistent. In the simple_plot_wxagg example, I had the
timezone info in my includes list only and it worked w/o incident. In
the simple_plot_gtk example, I needed to manually add

import pytz.zoneinfo.UTC

to my simple_plot.py script. Strange...

For me I've found that I've needed to include every level of a given
module individually to get it working, e.g. 'pytz', 'pytz.timezone'
and 'pytz.timezone.UTC'. After that py2exe works for me.

This (to me) is an example of how stuff which dynamically imports
modules at runtime trips up stuff like py2exe (I believe the py.test
folks are losing a lot of hair over dynamic imports in their testing
magic too). What I think is happening here (and in encodings) is that
normal usage involves just importing the toplevel module in your app's
code, and at runtime you invoke a call which then goes and imports the
module supplying the code you need. So when py2exe analyses the code,
it doesn't see your runtime import and misses the relevant module.

Adding an explicit import in your app should be pretty much the same
as using a py2exe include, except that it introduces some overhead at
runtime. To handle every timezone your would have to import every
timezone in your app, whereas with py2exe's includes you just specify
what to stick in the zip and the app can import just the timezone it
needs at runtime. Theoretically anyway :slight_smile:

To add fun to the mix, any package which dynamically imports stuff at
runtime usually has to be careful to either be aware of how it lives
in a zip when frozen, or not to do anything dependant on it's file
path.

Also, what kinds of files should be in the includes list? For example,
in Michael's list, he includes

   "matplotlib._na_image",
   "matplotlib._na_transforms",
   "matplotlib._nc_image",
   "matplotlib._nc_transforms",

but not

   "matplotlib._image"
   "matplotlib._transforms"

The latter two are python files, the former extension code. Do you
typically need to manually point py2exe to the extension files?

I've found py2exe has given me difficulty when looking for extensions,
so my list of includes represents partially extensions I've found to
be missing in frozen apps when trying to run them and partially every
other extension I've come across for good measure (since I was doing a
build, crash, add missing extension loop, I decided to add them all).
Depending on how apps and modules handle imports, py2exe seems to be
able to pick up pure python stuff more easily than python extensions.

All this could be just a mix of my particular setup and the
applications I deal with, no two people's py2exe problems ever seem to
be the same :slight_smile:

All the problems centre around py2exe's module finding logic, every
problem I've encountered has been due to py2exe missing out on one or
two modules (in particular ones which do very dynamic imports at run
time as oppose to import time), so there is a lovely cargo cult feel
to my includes list, I decided the five minutes of adding all the
includes I might need from a given package was worth it, rather than
the repeated half hour of tracking down people's problems when running
the apps.

Anyway, the wxagg and gtk examples in the updated
http://matplotlib.sourceforge.net/py2exe_examples.zip build and run on
my machine. They are a bit of a hack in that I don't really
understand why/how/when the includes work. If someone can rationalize
these scripts, improve them, extend them, whatever, send the updates
my way.

I'll have a go with them and see how they fair under my esoteric
setup. I'm going to bet that I'll have problems no one else does :wink:

Michael

-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click