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. 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. 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. > If you can tell me how a brand new 4Suite release can work OOTB witth > any PyInstaller version, I'd be glad to hear it. As you know, I will have to find time to implement pkg_resource data loading support before that can happen. Later, you will have to fix 4Suite so to play by the rule with relative imports in your C extensions and call the import hooks registered by the client, instead of bypassing them. It is my understanding at this point that, after both these things have happened, 4Suite will work OOTB with PyInstaller. -- Giovanni Bajo _______________________________________________ PyInstaller mailing list [email protected] http://lists.hpcf.upr.edu/mailman/listinfo/pyinstaller
