Re: [Pythoncard-users] Re: Python distribution problems

[Kevin A. <al...@se...>]

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