nad at acm
Aug 15, 2012, 2:30 AM
Post #4 of 7
(759 views)
Permalink
|
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 <E0FF98C8-13D2-44CA-B890-03F12D836F4A [at] gmail>,
Raymond Hettinger <raymond.hettinger [at] gmail> 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 [at] gmail>,
Jesse Noller <jnoller [at] gmail> 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 [at] acm
_______________________________________________
Python-Dev mailing list
Python-Dev [at] python
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/list-python-dev%40lists.gossamer-threads.com
|
smime.p7s
