[Pythonmac-SIG] Why Do I Explicitly Need MacPython

[Ronald Oussoren]

On Oct 3, 2006, at 6:24 PM, Christopher Barker wrote:

>
> So far, it appears the easiest way to make a package easy to  
> install for
> a mac user is to make a *.mpgk of it. In fact, I've advocated for  
> years
> that the best way to make python accessible on all platforms if to  
> have
> packages in a "native" format -- that means rpms on rpm based linux
> systems, MS installers for windows, and mpkgs for the Mac.

That depends on how you look at things ;-). As a system administrator  
I really prefer software that is installed using native packages,  
that way I have one repository to query to see what is installed. The  
disadvantage of using a native package system is that the python user  
has to remember which tool he has to use on every partical box  
instead of using something familiar.

But for the mac we don't really have a choice, as you mentioned Apple  
doesn't ship a good package manager anyway, so we won't miss out a  
lot when we don't use .mpkg's.
>
> Ronald Oussoren wrote:
>> I'm rather happy with setuptools, there are some cosmetic problems
>> (like the header-file thingy), but the core seems pretty well thought
>> out.
>
>> This features is apparently also on the list for the 0.7 release (but
>> not yet implemented).
>
> Which reinforces that setuptools is a good option to pursue.

Yup.

>
>> I'm -0 on this. Easy-install is very convenient and I wish it were  
>> part
>> of Python 2.5 but it isn't. MacPython is at this point in time "just"
>> the official binary distribution of the python.org tree.
>>
>> Growing it beyond that (that is include third party libraries and  
>> tools)
>> could be useful, but even then I'd be more inclined towards adding
>> useful GUI tools than libraries.
>
> Which is what I'm talking about. I don't agree that "MacPython is at
> this point in time "just" the official binary distribution of the
> python.org tree". I've certainly got the impression that the goal  
> is to
> make Python work smoothly and "natively" on the Mac. I suppose the  
> only
> real additions are the pythonw (now called python) front end and a
> little tweaking of shell start-up scripts, but those are important.

Sure, but at this point in time all that work is done within the  
boundaries of the official python.org tree. That's not to say that  
this cannot change, and IMHO this should change at some point. I'd  
love to see better GUI tools than IDLE included with the official  
distribution.
>
> Maybe installing setuptools by default is the thin end of the  
> wedge, but
> I think it's critical that we do have a standard and easy way for  
> people
> to install packages.

There is one major problem with setuptools w.r.t. this: at least some  
of the python.org maintainers really dislike it for some reason or  
the other.  That makes it including setuptools in the official python  
distribution for the mac a bit hairy.

>
> setuptools is still a bit of a mystery to me, but I'm still  
> confused as
> to why it is more than trivial to make a small gui that will:
>
> Pop up a dialog when you click on a *.egg, with a message like:
>
> Would you like to install the python package: blah-blah-blah:
> [install] [cancel]
>
> if [install] is clicked, it would ask for the admin password, then
> install the package.
>
> If dependencies are required, it would pop up another dialog:
>
> The following other packages are required to install this one.  
> Would you
> like these to be auto-downloaded for you, or would you like to  
> download
> and install them by hand?
> [auto-download] [I'll do it]
>
> Thats it. I think setuptools provides that functionality at this  
> point.
> Am I wrong?
>
> Key is that there is a default way to download an egg, click on it,
> select all the defaults in a series of dialogs, and get your package
> installed.

Building such a gui would be straightforward if setuptools had the  
hooks to do so. Last time I checked setuptools had some hooks, but  
isn't capable of playing nice with a GUI event loop.

My guess is that it is much more convenient to build a very shallow  
wrapper around easy_install, basicly just a window with a textbox  
where you can enter an easy_install command-line and larger textview  
to show the output of easy_install. Double-clicking on an egg can  
open this window with the right command-line filled in.

Ronald
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3562 bytes
Desc: not available
Url : http://mail.python.org/pipermail/pythonmac-sig/attachments/20061003/3a7f0b07/attachment.bin