On Sunday 06 August 2006 7:09 pm, Giovanni Bajo wrote: > Jeremy Kloth wrote: > >> There are at least two big issues. First, the user has *still* to be > >> aware of the existence of the hook and explicitally call it in its > >> setup.py file. Second, this kind of "hooks" cannot be chained > >> together: what if my application uses 3 or 4 third party modules, > >> each one with its own distutils derived classes? > > > > Sure there is a one-liner that needs to be used instead of the > > standard py2exe one, but it is better telling users "sorry our brand > > new shiny release cannot be frozen until PyInstaller cuts a new > > release that supports our changes". > > Your sarcasm is not welcomed here.
Sorry if that sounded harsh, but I was responding to the comment that the code that is Ft.Lib.DistExt.Py2Exe is hackerish. I don't see what is bad there; it extends two methods and installs itself as the command class (in the same way that py2exe itself installs the class). > If you do not understand the two > distinct and objective technical merits of incorporating the hooks within > the freezing programs ala PyInstaller rather than within the third party > extension itself, it is not my problem. Don't get me wrong, I would prefer of all freezing applications Just Worked. But in reality, that will not be the case. What I want is something that I can point my users to and tell them "to this and freezing Just Works". If it is embedded in the freezing tool, great, but I really don't care where it comes from. > It is not even my fault if you > wast^H^H^H^Hused your time already on py2exe, and you did it in a way that > it's useless to users needing both 4Suite and any other moderately large > library. I highly doubt that the way that the extension is implemented conflicts with other libraries. If it did, I'm prettty sure that we would have had some one report it by now, the code is 18 months old. Anyway, I've looked into PyInstaller hooks, and discovered that at least 11 of them would be need for 4Suite if we would like to keep the included modules to a minimum. Nothing but an observation. Say that the hooks would be bundled with PyInstaller, who's responsibility is it to keep them current/correct? I'm curious as to how to keep everything working when the "hidden" imports change. It seems to me that 4Suite would end up bundling the hooks and having the the user add "hookspath=['path/to/4Suite/hooks']" to their spec file. Not too different from "manually write in your setup.py file to make them work" to quote an earlier message. In the end, all I want is for all 4Suite users to be able to use the freezing application of their choice and to have it Just Work. Until PyInstaller catches up with the others for support of zipimports and data files from those imports, I cannot recommend its use. Actually, I'm pretty sure that it won't even work, but that's neither here nor there. And BTW, I plan on changing the PyImport_ImportModuleEx functions to plain PyImport_ImportModule, even though PyInstaller is the only application that has issues with it. -- Jeremy Kloth http://4suite.org/ _______________________________________________ PyInstaller mailing list [email protected] http://lists.hpcf.upr.edu/mailman/listinfo/pyinstaller
