[Pythonmac-SIG] My stab at a new page

[Bob Ippolito]

On Feb 10, 2006, at 1:53 PM, Bob Ippolito wrote:

>
> On Feb 10, 2006, at 1:06 PM, Kevin Walzer wrote:
>
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> Christopher Barker wrote:
>>> Louis Pecora wrote:
>>>> This seems to be where this argument goes:  the user/newbies vs.  
>>>> the
>>>> developers.
>>>
>>> I don't think so. This entire conversation is about supporting the
>>> newbies. The disagreements are about how best to do that.
>>>
>>>>  You shouldn't be forcing everyone to adopt a python system
>>>> that then suits your marketing model.
>>>
>>> I know why I'm pushing for the "Install the 2.4 version" approach,
>>> and
>>> it's precisely to support newbies, not to fit a marketing model.
>>>
>>> If we make it clear that there is one "Standard" way to do python
>>> on the
>>> Mac, then it's easier for everyone:
>>>
>>> - Newbies don't have to make a decision they don't understand the
>>> implications of.
>>>
>>> - We don't have to field questions about more than one version.
>>>
>>> - When they need to add an extension package, there is only one
>>> set of
>>> pre-built packages to look at.
>>>
>>> - Extension package builders and maintainers only need to target one
>>> version, and as a result, more packages will work on the Mac. (you
>>> should see what's in the matplotlib setup.py: a fragile mess
>>> inside the
>>> "darwin" section, looking around for whether you're running fink, or
>>> darwinports, etc. so that libs can be found. What a pain!)
>>>
>>> Those are some of the reasons that I think we need to establish a
>>> single, standard, "Recommended by the MacPython community" version.
>>
>> +1 for what Chris is advocating here.
>>
>> A good model for this is Tk Aqua: see http://
>> tcltkaqua.sourceforge.net.
>> For the past few  years this has been the standard way to get the
>> "latest and greatest" Tcl/Tk for the Mac. It's been superseded a
>> bit by
>> ActiveState's distribution, but because ActiveState has licensing
>> restrictions, that's not for everyone.
>>
>> ActivePython is also an example to consider that's a little more
>> relevant. Not to recommend ActivePython itself, as its licensing is
>> more
>> restrictive than the build that will result from this discussion,
>> but it
>> is a self-contained, easily-installed, well-documented, and up-to- 
>> date
>> bundle of Python and packages.
>
> The licensing issues with ActivePython were clarified last year:  It
> is explicitly legal to redistribute self-contained application
> bundles (a la py2exe or py2app) built with ActiveState's
> distributions.  This gives it a leg up on Apple's distro (which has
> no such clause; components of OS X are not redistributable), and
> makes it a candidate Python distribution for almost anyone.
> Personally, I have tried it out a bit on one of my machines and found
> a couple bugs that were quickly resolved.  Nothing outstanding and
> nothing major, and the turnaround was quick.
>
> Currently, ActivePython on Mac OS X is almost exactly the same thing
> that we're going to be shipping with the universal build of 2.4.2.
> The differences will be:
>
> 1. They aren't shipping readline, we will
> 2. We'll probably ship universal first
> 3. I don't believe they have the PATH hack in their installer
> 4. They ship with an ActivePython icon for pythonw, we'll stick with
> the current icon.

5. We're also shipping some bug fixes that aren't in Python yet, like  
doing the select.poll check at runtime instead of configure time.   
Mac OS X 10.4.4 has a fully working poll implementation, but I  
believe some point version back in the day didn't.  Some applications  
depend on select.poll and associated constants being there.  I can't  
think of anything open source at the moment, but I know people who  
have internal apps that depend on poll because it has higher  
performance for their deployment environment.

-bob