Why Do I Explicitly Need MacPython

In article 
<6a36e7290609201721v4f8725aet97b74b27c225deeamail.gmail.com>,
 "Bob Ippolito" <bobredivi.com> wrote:

> >...
> > I've started looking into that. However, my
strong suspicion is that the
> > way to build a MacPython installer that can use a
user-installed Tcl/Tk
> > is to *have* a user-installed Tcl/Tk installed
before building python
> > for the MacPython installer package.
> 
> That's one way, another is to use install_name_tool as
part of the
> build procedure to change what _tkinter.so looks for,
and a third is
> to include a subset of a recent Tcl/Tk in the build
like the Win32
> installer does. The third option is ideal as far as how
we do
> everything else goes.

I confess I've not figured out how this would work. Where
would the 
installed Tcl/Tk go, to avoid colliding with a
user-installed Tcl/Tk.

I'm a bit happier using a user-installed Tcl/Tk (if found)
because it's 
still not completely stable and the user should easily be
able to 
upgrade to a newer (less buggy) version if one comes along.

> Personally, I don't care much about this issue. I
don't use Tcl/Tk
> Aqua, and it seems the only third party builds readily
and obviously
> available are PPC-only, and I use a MacBook Pro.
Creating a bug and/or
> patch makes it a lot more likely that something will
happen
> (especially a patch).

I wasn't sure what to patch, so I submitted bug report
#1563046.

The bug report includes a python script that (based on your
recipe) 
modifies _tkinter.so to use a user-installed framework
Tcl/Tk if it 
finds one.

I'm hoping the script will run as part of the installation
of MacPython.

-- Russell

_______________________________________________
Pythonmac-SIG maillist  -  Pythonmac-SIGpython.org
http://mail.python.org/mailman/listinfo/pythonmac-sig

On Sep 21, 2006, at 8:01 PM, Russell E. Owen wrote:

> In article
> <6a36e7290609201721v4f8725aet97b74b27c225deeamail.gmail.com>,
>  "Bob Ippolito" <bobredivi.com> wrote:
>
>>> ...
>>> I've started looking into that. However, my
strong suspicion is  
>>> that the
>>> way to build a MacPython installer that can use
a user-installed  
>>> Tcl/Tk
>>> is to *have* a user-installed Tcl/Tk installed
before building  
>>> python
>>> for the MacPython installer package.
>>
>> That's one way, another is to use
install_name_tool as part of the
>> build procedure to change what _tkinter.so looks
for, and a third is
>> to include a subset of a recent Tcl/Tk in the build
like the Win32
>> installer does. The third option is ideal as far as
how we do
>> everything else goes.
>
> I confess I've not figured out how this would work.
Where would the
> installed Tcl/Tk go, to avoid colliding with a
user-installed Tcl/Tk.
>
> I'm a bit happier using a user-installed Tcl/Tk (if
found) because  
> it's
> still not completely stable and the user should easily
be able to
> upgrade to a newer (less buggy) version if one comes
along.
>
>> Personally, I don't care much about this issue. I
don't use Tcl/Tk
>> Aqua, and it seems the only third party builds
readily and obviously
>> available are PPC-only, and I use a MacBook Pro.
Creating a bug  
>> and/or
>> patch makes it a lot more likely that something
will happen
>> (especially a patch).
>
> I wasn't sure what to patch, so I submitted bug report
#1563046.
>
> The bug report includes a python script that (based on
your recipe)
> modifies _tkinter.so to use a user-installed framework
Tcl/Tk if it
> finds one.
>
> I'm hoping the script will run as part of the
installation of  
> MacPython.

As I noted in a comment in that bugreport I'm not to keen
on that. I  
don't mind shipping the script ( or a GUI version of it) in
the  
application folder for users that want to switch to a newer
Tk, or  
even ship a minimal version of Tcl/Tk inside the
Python.framework,  
but running this script during installation means that (a)
the script  
must be 100% correct in all situations and (b) we'll end up
with  
Python installations that are slightly different which
won't be fun  
to investigate when someone reports a problem with tkinter. 

Especially because users might not even realize they have a
copy of  
Tk in /Library/Frameworks.

Ronald
>
> -- Russell
>
> _______________________________________________
> Pythonmac-SIG maillist  -  Pythonmac-SIGpython.org
> http://mail.python.org/mailman/listinfo/pythonmac-sig

_______________________________________________
Pythonmac-SIG maillist  -  Pythonmac-SIGpython.org
http://mail.python.org/mailman/listinfo/pythonmac-sig