Raymond raises a couple of issues and Jesse comments on those and brings up another issue. Let me address each in turn (and I apologize for the length!): 1. Gatekeeper singing on 10.8 In article , Raymond Hettinger wrote:

On Mountain Lion, the default security settings only allow installation of applications downloaded from the Mac App Stored and "identified developers".

We need to either become an "identified developer" or include some instructions on how to change the security settings (System Preference -- General -- Unlock --Select the "Anywhere" radio button -- Install Python -- Restore the original settings -- and Relock). Changing the security settings isn't appealing because 1) it weakens the user's security 2) it involves multiple steps and 3) the user will see an unsettling warnings along the way.

Yes, Gatekeeper support is a known desirable feature for OS X 10.8 (Mountain Lion). There are a number of issues involved, involving code, process, and the PSF as a legal entity. Rather than going into all the gory details here, see http://bugs.python.org/issue15661 which I've opened to track what needs to be done. Quick summary is that we need to change the installer format that is used to be able to participate in the installer singing program and the PSF will likely need to be involved as the legal entity "owning" the certificates that need to be signed. Ronald and I are aware of the issues but, to be honest, this has been a lower-priority issue compared to others for the Python 3.3.0 release. Now that 3.3.0b2 is out and things seem to be in pretty good shape, this issue is now in the top set of my list and I have been working on it recently. By the way, it's not necessary to use System Preferences to change the security settings, although Apple doesn't make it obvious that this is the case. As documented here (http://support.apple.com/kb/HT5290) and in the online help, you can override the signing check by using control-click on the installer mpkg file and selecting Open using ... Installer (or use spctl(8) from the command line). Thread-tie: the current ActiveTcl installers for OS X are also not yet signed so attempting to install them on 10.8 currently results in the same user experience as with python.org installers. In article <5432C23E-CABB-476E-966C-164209BA47AE@gmail.com>, Jesse Noller wrote:

I think becoming an apple signed developer to get a cert is the best approach.

If anyone wanted to approach apple about open source/non profit gratis licenses, that would be appreciated.

Otherwise I could do it / fund it from the PSF board side, which I am happy to do.

Thanks, Jesse. There seems to be a fairly straightforward process for a corporate entity to request a development team membership from Python (at nominal cost, see the references in the opened issue). As the developer ID program is new to me, I have been intending to propose something officially to PSF officers once we were further along with implementation and testing. With Ronald's concurrence, I will make sure to follow up with you and/or Van when we are further along. 2. Tcl/Tk on OS X Raymond:

Another unrelated issue is that the instructions for updating Tcl/Tk are problematic. In the past few months, I've witnessed hundreds of people unsuccessfully trying follow the instructions and having an immediate unpleasant out-of-the-box experience when IDLE crashes. I suggest that we stop being so indirect about the chain of footnotes and links leading to a Tcl/Tk download. I would like to see a direct Tcl/Tk updater link side-by-side with our Python installer link at http://www.python.org/download/releases/2.7.3/ [...] I would like to see our download page have something more simple, affirmative, positively worded and direct. For example:

* Mac OS X 64-bit/32-bit Installer (3.2.3) for Mac OS X 10.6 and 10.7 [2] (sig). To run IDLE or Tkinter, you need to update Tcl/Tk to ActiveTcl 8.5.12 http://www.activestate.com/activetcl/downloads .

I am open to changing the wording. However, as I've noted in the past, I think it's problematic to use wording that implies you can unconditionally download and install ActiveState's Tcl. I really appreciate the great work that the ActiveState folks do and am happy to recommend people to use it. But not everyone can without cost. The free (as in beer) ActiveTcl Community Edition is not open source and it is released with a license that restricts the use of some parts of ActiveTcl, the pieces that ActiveState have developed themselves. That's a perfectly understandable business decision. I am not a lawyer so I'm not in a position to say to our users whether or not they can legally download and use ActiveTcl without entering into some other license arrangement. That's one reason why the links send users to the special page. I'd would be happy to see wording on the release pages that incorporate that sense. I'll see what I can come up with and propose something. Let me know if you have any specific suggestions or if you think my concerns are misplaced. http://www.activestate.com/activetcl/license-agreement http://www.python.org/download/releases/3.3.0/ http://www.python.org/download/mac/tcltk/

Someone did add a note the the IDLE startup screen to the effect of: "WARNING: The version of Tcl/Tk (8.5.9) in use may be unstable. Visit http://www.python.org/download/mac/tcltk/ for current information." In some ways this is progress. In others, it falls short. If IDLE crashes, you can't see the message.

The warning message when IDLE.app is run with the buggy Apple-supplied 10.6 Tcl/Tk has been available since 3.2 and 2.7.2 (Issue10907). I did recently update all branches to warn about the 10.7/10.8 versions as well; they are not as totally broken as 10.6 was but can still crash easily from the "wrong" user keyboard input.

If you have installed the ActiveTCL 8.5.12 update, you still see the warning eventhough it isn't necessary.

That should not be the case with installers downloaded from python.org. If you can reproduce, please check to see the actual path to the Tcl and Tk frameworks. Probably the easiest way for IDLE.app is to launch "/Applications/Utilites/Actiity Monitor.app", select the IDLE process and click on Inspect. In the list of open files, you should see /Library/Frameworks/Tcl.framework/Versions/8.5/Tcl and /Library/Frameworks/Tk.framework/Versions/8.5/Tk if ActiveTcl is being linked or /System/Library/Frameworks/Tcl.framework/Versions/8.5/Tcl and Tk if the Apple system versions are being used. If you are using Pythons from another source or self-built, there is no guarantee that they will link to the ActiveTcl versions without taking some steps during building. Let me know if I can help with that.

Also, I don't link that the referenced page is so complex and that it is full unsettling warnings, important notices, do-not-use advice, mentions of instability, etc.

Well, the situation *is* pretty complex. We support a *lot* of configurations and there are a lot of gotchas. We have have taken some steps to simplify things, like dropping installer support for 10.3 and 10.4 with Python 3.3 but unfortunately the most problematic OS X releases for Apple Tcl are the most recent ones (10.6, in particular). Prior to 3.3.0 release, I intend to review and revise it. Wording change suggestions are welcome! But I totally agree that the user experience is not good. The only way I see to make a major improvement is to get into the business of building and supplying Tcl/Tk with the OS X installers, as is currently done for the Windows installers. Now that the Mac Tcl community has been getting more involved in maintaining the Cocoa port themselves and things are getting more stable (and Apple continues to appear to be uninterested), perhaps it is time for us to bite the bullet. I've opened Issue15663 to look into that for 3.4 (and *possibly* for earlier maintenance releases). 3. Download instructions and Xcode Jesse:

I also concur with Raymond that the download/install instructions could be simplified. Noting for users that rather than downloading Xcode, they can just download the OSX Command Line Tools installer and easy_install/pip/etc will just work would also be nice

The Mac section of the Python docset is woefully out-of-date (from long before I got involved!) and I plan to give it a major update for 3.3.0. The whole business of what's needed to build extension modules on OS X got *much* more complicated with Xcode 4 (the default for 10.7 and 10.8) and each minor release of Xcode 4 has brought new changes. The introduction of the stand-alone Command Line Tools (with Xcode 4.2?) was a nice addition but there are gotchas with using it, for example, extension building with current Python 3.2.3 installers do not work out-of-the-box with the CLT because the CLT do not provide SDKs. 2.7.3 is better but neither of the current 32-bit installers will work out of the box with Xcode 4. A lot of work has gone into 3.3.0 to make extension building and building Python itself play more nicely with Xcode 4 without breaking support for older versions. Some subset of that support will get backported for 2.7.4 and 3.2.4 once 3.3.0 is done. Also, if network bandwidth and disk space usage are not major concerns, it may now be procedurally easier for most people to install Xcode 4 than the Command Line Tools package since the former is now available for free download from the Mac App Store while the latter still requires registering for a (free) Apple Developer Id and download from the Apple Developer site. And since Xcode 4 has been partitioned up into smaller downloadable components, the Xcode download is smaller as it is not necessary to download everything (including iOS development tools) as was the case with Xcode 3. -- Ned Deily, nad@acm.org

On Wed, 15 Aug 2012 02:30:17 -0700 Ned Deily wrote:

1. Gatekeeper singing on 10.8

[...] Quick summary is that we need to change the installer format that is used to be able to participate in the installer singing program

I first thought Apple had gone poetic and then I realized it's a typo (singing / signing). Too bad. Regards Antoine. -- Software development and contracting: http://pro.pitrou.net