From: Michael T. <mic...@gm...> - 2005-04-12 10:25:13
|
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 |