From: Kevin A. <al...@se...> - 2005-04-05 18:21:49
|
On Apr 5, 2005, at 12:48 AM, normanwinn wrote: > ka wrote: >> Secondly, once we have a viable 1.x release, I would like to have a >> single installer option for Python, wxPython, and PythonCard on the >> Windows platform > > The very fact that you should need to contemplate this demonstrates > the severity of the problem. I already have versions of Python that > came with Zope, with Open Office, then I'll have another with > PythonCard and another with Dabo. Where will this stop? Each time I > want to upgrade I end up upgrading n versions of Python? This is > folly. > > What is the alternative? I can't have an answer as I am not at the > interior of an open source effort. Perhaps a standard test suite for > Python? Perhaps co-ordinated upgrade days? Perhaps sterner control > over the standard Python library? > > Then the exe tools. With py2exe I ended up with the tcl library in my > 'exe' package when compiling a command line tool! I don't know how > many megabytes I had to distribute. I didn't bother. I then found > exemaker: > > http://effbot.org/downloads/index.cgi/exemaker-1.2-20041012.zip/README > > but this, while being very handy on a system that has Python, is not a > standalone exe so can't be distributed. > > Please accept that I am not knocking (does that translate into > American). I hope my observations can contribute to a process that > will make Python tools available to all, > > Norman Winn > Actually, what I was talking about was more like an uber installer that would install Python, wxPython, and PythonCard in one shot, so people didn't have to download up to 3 different EXEs and run each installer separately. Another way to think of it would be Python that included wxPython and PythonCard as part of the distribution. This wouldn't be a special copy of Python like you have with some Zope/Plone and OpenOffice installs. Furthermore, the individual PythonCard release zip, tar.gz, and EXE installer would still be there. I'll be adding a Mac disk image installer of the PythonCard distribution as soon as I figure that one out. :) This is a separate issue from building standalones for end-users. py2exe and py2app both do their best to figure out required modules. In the case of PythonCard, there is an import of the Image (PIL) module to support easy display of PIL images in PythonCard apps, so a generic standalone build using py2exe will bring in PIL and thus tkinter and its Tcl code. But it is simple enough to exclude modules and libraries that you know you're app doesn't use and this is even documented in the minimalStandalone example. The standaloneBuilder tool will likely have options for excluding common extra libs that most apps wouldn't use. One of the biggest problems with all standalone applications is simply the size of the distribution. It is definitely nicer if you're able to just distribute the plain Python code of a normal PythonCard application, so in a controlled environment I would recommend that people go ahead and install the base Python, wxPython, and PythonCard packages, especially in a computer lab or enterprise installation. On Windows, if there is a security concern over people double-clicking a .py, .pyw, .pyc, .pyo, etc. file then it is simple enough to remove that file association. A lnk file can be used to provide a full path to Python and the executable script with any command-line args, so that can be used instead of a double-clickable exe. ka |