Am 30.12.2010 22:50, schrieb Giovanni Bajo: > Feature #1 would not provide a great benefit for the user, IMO. The only There are two reasons for feature #1:
a) Those who do not want to install into site-package do not need to. If the structure is crafted decently, pyinstaller can still be used without installation. b) It's an improvement for those who want to install pyinstaller using easy_install/pip. As long as there are not disadvantages for others, it it not relevant that others will not have a benefit. Not everybody can benefit from every improvement. c) But most important: It's a prerequisite for > IMO a python *application* > is a different beast from a python *package* and should follow different > rules for distribution and installation. While agree with you here: There simply are no different rules. There is no distinction between packages and applications. Other applications can be installed using setup.py, too. E.g. www.tryton.org, where the client contains a GTK-GUI and the server is running as a daemon. Regarding feature #2: My projects are using setup.py for distribution, I need pyinstaller only for packaging Windows executables (and may add OSX), since Windows users are not able to install a Python application. setup.py already includes all information which is required to create a distribution package. I build several packages, upload them to Origo (where the file repos lives) and register at pypi. All with a single call. Currently, pyinstaller does not fit into this process, it even breaks this process. But worst: I let setuptools create the scripts from entry_points. pyinstaller can not recognise the hidden imported modules loaded by load_entry_point() (see ticket #305). This could be solved quite easy if there would be some distutils-command 'pyinstall'. The planned pyinstaller.py tool (ticket #232) is already a big step into this direction. So everything which is missing is such a distutil-command (ticket #32). Again, it's an enhancement not everybody may need. If you dislike it, just do not use it :-) Others will be glad about this. > If you take a look at the work being done in the > makespec_ng branch, we are planning to push this design even further, > with a new and more powerful .spec file that can even be updated by > import hooks to add library-specific options under user's control (eg: > PyQt4 hook can add an option to .spec file to let the user decide which > Qt plugins to bundle, etc.). Hmmm, well ... To be honest: I do not see what's the big benefit over a distutils-based approach. But here, too: This is an enhancement, some would not need. This time it's me :-) -- Schönen Gruß - Regards Hartmut Goebel Dipl.-Informatiker (univ.), CISSP, CSSLP Goebel Consult Spezialist für IT-Sicherheit in komplexen Umgebungen http://www.goebel-consult.de Monatliche Kolumne: http://www.cissp-gefluester.de/ Goebel Consult mit Mitglied bei http://www.7-it.de
smime.p7s
Description: S/MIME Cryptographic Signature
