On ven, 2010-12-31 at 17:25 +0100, Hartmut Goebel wrote: > 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.
How do you propose to change the way PyInstaller is executed by the user when installed through pip/easy_install? Where do you plan to move config.dat, which is currently created by Configure.py, and couldn't be created in site-packages which is not user-writable in UNIX systems? And what about the bincache directories? [[ BTW I think we could eventually move away from Configure.py altogether -- I don't see such a gain from having a separate configuration step, I think Build.py could simply rediscover whatever it needs at runtime. But this is a separate refactoring. ]] > > 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. I disagree. An application has a platform-specific installation procedure on each platform which might or might not be similar to the way a Python package is distributed. The fact that some applications try to (ab)use distutils to distribute themselves does not mean that it is the way PyInstaller should work. My own plan to cover the distribution step is to have a separate binary (Deploy.py, to be run after Build.py) which would: * Windows: create an installer through InnoSetup, packaging all the required files discovered by Build.py plus user-defined files. * Linux: create a DEB or RPM. * Mac: create a DMG. This is totally different from what a distutils package look like. For instance, thinking of just Windows, a full application might not fit into the simple installer wizard that bdist_exe produces, which is not thought for a generic installation of applications, but simply to find out existing Python installations (which are not even required by an application!) and unpack into site-packages. The same applies for the other platforms. The good news is that I already have all the above code written and it's working quite well, but it's under a proprietary license at the moment. I'm working towards making it GPL and releasing it. > 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. I think I'm missing something here -- are your projects standalone Windows applications (which just happen to be written in Python), or are they Python packages meant for a Python developer to be used? PyInstaller (in my mind) is meant for standalone Windows/Linux/Mac applications. I wouldn't even think of uploading such an application to pypi. If you're working on Python packages (PyPI = Python Package Index), why do you need PyInstaller at all? > > 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. Well: http://docs.python.org/library/distutils.html ====================== The distutils package provides support for building and installing additional modules into a Python installation. ====================== I don't see any connection between "installing additional modules into a Python installation" and PyInstaller, which is "a program that converts (packages) Python programs into stand-alone executables" that do not require a Python installation at all. -- Giovanni Bajo :: Develer S.r.l. [email protected] :: http://www.develer.com Blog: http://giovanni.bajo.it Last post: Compile-time Function Execution in D -- You received this message because you are subscribed to the Google Groups "PyInstaller" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/pyinstaller?hl=en.
