On 17 March 2016 at 12:42, Anthony Tuininga <anthony.tuini...@gmail.com> wrote: > What I mean by that is "hack the code of the dateutil module so that it > doesn't look for its data within the file system where the module exists". > That has been done for a number of modules and packages to make it "freezer > friendly" and you can do the same for this one. If that sounds scary then > your only option is to find another package that does what you want that > doesn't have this issue....or wait for me to address this issue in a general > way.
In this case, the dateutil package does actually use pkgutil.get_data to get the zoneinfo file (you can see that in the traceback the OP provided), so that will work frozen. However, there's some functionality in there that *updates* that file (I've no real idea why it needs to do that) and that functionality doesn't work when frozen, as the data file is read only. The traceback shows the code trying to call a "write" method on the (read only) file object returned from get_data. But as you say, fixing this either needs someone to raise an issue with the dateutil package to work when frozen (it may also fail when on a read-only filesystem), or the OP to implement his own hack to the package to do that. Obviously the better long term solution is to get the upstream package fixed, and if the OP isn't comfortable hacking the module, that may be his best approach. Paul ------------------------------------------------------------------------------ Transform Data into Opportunity. Accelerate data analysis in your applications with Intel Data Analytics Acceleration Library. Click to learn more. http://pubads.g.doubleclick.net/gampad/clk?id=278785231&iu=/4140 _______________________________________________ cx-freeze-users mailing list cx-freeze-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/cx-freeze-users
