[Matplotlib-users] Re: py2exe Problems...

[Werner F. B. <wer...@fr...>]

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 <jdh...@ac...> wrote:
> 
>>>>>>>"andrea" == andrea gavana <and...@ti...> writes:
>>
>>    andrea> 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 :)
> 
> 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 :)
> 
> 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 ;)
> 
> 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