Re: [Python-Dev] Installation on Macs

2012-08-15 Thread Ronald Oussoren

On 15 Aug, 2012, at 2:33, 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. 

You don't have to change the security settings, choosing "open" from the 
context menu will to the trick. This is only needed for the installation after 
downloading using a browser that supports Apple's quarantine solution (such as 
Safari, I don't know if other browsers mark files as being quarantined). 

That said, signing the installer would be more friendly to users and Ned has 
opened an issue for this: 

> 
> 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/
> 
> 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.  If you have installed the ActiveTCL 8.5.12 
> update, you still see the warning eventhough it isn't necessary.  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.  

Tk on OSX is a mess. The version that Apple ships tends to crash a lot on even 
slightly complicated code (or just someone that tries to input accented 
characters).  The ActiveState download is better, but there are still crashes 
and unexpected behavior with that version.  AFAIK most bug reports about IDLE 
not working correctly on OSX are due to issues with Tk, Ned should know more 
about that as he's the one that tends to look into those issues.

> 
> 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 
>  .
> 
> That saves you from having to click a links down to a footnote at the bottom 
> of the page  that sends 
> you to  which is  another page full 
> of tables, warnings,etc that leads you to the Apple 8.5.9 section 
>  which is a dead-end 
> because there are still known issues with 8.5.9, leaving you with the 
> ActiveTCL section 
>  which has a 
> paragraph of text obscuring the link you actually needed: 
> http://www.activestate.com/activetcl/downloads .
> 
> I applaud that some effort was made to document a solution; however, in 
> practice the daisy chain of footnotes, tables, and links has proven 
> unworkable for most of the engineers I've been working with.

+1 on adding direct download links for Tk to the main download page.

Ronald
> 
> 
> Raymond
> 
> ___
> Python-Dev mailing list
> [email protected]
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: 
> http://mail.python.org/mailman/options/python-dev/ronaldoussoren%40mac.com



smime.p7s
Description: S/MIME cryptographic signature
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com


Re: [Python-Dev] Installation on Macs

2012-08-15 Thread Ned Deily
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 <[email protected]>,
 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 
>  .

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 

Re: [Python-Dev] Installation on Macs

2012-08-15 Thread Antoine Pitrou
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


___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com


Re: [Python-Dev] Installation on Macs

2012-08-15 Thread Ronald Oussoren

On 15 Aug, 2012, at 11:30, Ned Deily  wrote:
> 
> 
> 
> 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.

Another advantage of installing all of Xcode is that the appstore will warn 
when a new version is available, and when you start Xcode you can still install 
the command-line tools (and Xcode will warn when that installation is out of 
date).

Ronald



smime.p7s
Description: S/MIME cryptographic signature
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com


Re: [Python-Dev] Installation on Macs

2012-08-15 Thread Ned Deily
In article <[email protected]>,
 Antoine Pitrou  wrote:
> 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.

Perhaps the installers periodically get together to silently sing _The 
Old Signing Blues_.

-- 
 Ned Deily,
 [email protected]

___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com


Re: [Python-Dev] [Python-checkins] cpython (merge 3.2 -> default): #11062: Fix adding a message from file to Babyl mailbox

2012-08-15 Thread Andrew Svetlov
Looks like it is the source of buildbot fail on Windows box.

On Wed, Aug 15, 2012 at 2:42 PM, petri.lehtinen
 wrote:
> http://hg.python.org/cpython/rev/7c8c6b905a18
> changeset:   78586:7c8c6b905a18
> parent:  78583:8d90fde35cc6
> parent:  78585:cbc1dc8cda06
> user:Petri Lehtinen 
> date:Wed Aug 15 14:36:14 2012 +0300
> summary:
>   #11062: Fix adding a message from file to Babyl mailbox
>
> files:
>   Lib/mailbox.py   |   2 +-
>   Lib/test/test_mailbox.py |  18 ++
>   Misc/NEWS|   2 ++
>   3 files changed, 9 insertions(+), 13 deletions(-)
>
>
> diff --git a/Lib/mailbox.py b/Lib/mailbox.py
> --- a/Lib/mailbox.py
> +++ b/Lib/mailbox.py
> @@ -1440,9 +1440,9 @@
>  line = line[:-1] + b'\n'
>  self._file.write(line.replace(b'\n', linesep))
>  if line == b'\n' or not line:
> -self._file.write(b'*** EOOH ***' + linesep)
>  if first_pass:
>  first_pass = False
> +self._file.write(b'*** EOOH ***' + linesep)
>  message.seek(original_pos)
>  else:
>  break
> diff --git a/Lib/test/test_mailbox.py b/Lib/test/test_mailbox.py
> --- a/Lib/test/test_mailbox.py
> +++ b/Lib/test/test_mailbox.py
> @@ -152,20 +152,16 @@
>  f.write(_bytes_sample_message)
>  f.seek(0)
>  key = self._box.add(f)
> -# See issue 11062
> -if not isinstance(self._box, mailbox.Babyl):
> -self.assertEqual(self._box.get_bytes(key).split(b'\n'),
> -_bytes_sample_message.split(b'\n'))
> +self.assertEqual(self._box.get_bytes(key).split(b'\n'),
> +_bytes_sample_message.split(b'\n'))
>
>  def test_add_binary_nonascii_file(self):
>  with tempfile.TemporaryFile('wb+') as f:
>  f.write(self._non_latin_bin_msg)
>  f.seek(0)
>  key = self._box.add(f)
> -# See issue 11062
> -if not isinstance(self._box, mailbox.Babyl):
> -self.assertEqual(self._box.get_bytes(key).split(b'\n'),
> -self._non_latin_bin_msg.split(b'\n'))
> +self.assertEqual(self._box.get_bytes(key).split(b'\n'),
> +self._non_latin_bin_msg.split(b'\n'))
>
>  def test_add_text_file_warns(self):
>  with tempfile.TemporaryFile('w+') as f:
> @@ -173,10 +169,8 @@
>  f.seek(0)
>  with self.assertWarns(DeprecationWarning):
>  key = self._box.add(f)
> -# See issue 11062
> -if not isinstance(self._box, mailbox.Babyl):
> -self.assertEqual(self._box.get_bytes(key).split(b'\n'),
> -_bytes_sample_message.split(b'\n'))
> +self.assertEqual(self._box.get_bytes(key).split(b'\n'),
> +_bytes_sample_message.split(b'\n'))
>
>  def test_add_StringIO_warns(self):
>  with self.assertWarns(DeprecationWarning):
> diff --git a/Misc/NEWS b/Misc/NEWS
> --- a/Misc/NEWS
> +++ b/Misc/NEWS
> @@ -13,6 +13,8 @@
>  Library
>  ---
>
> +- Issue #11062: Fix adding a message from file to Babyl mailbox.
> +
>  - Issue #15646: Prevent equivalent of a fork bomb when using
>multiprocessing on Windows without the "if __name__ == '__main__'"
>idiom.
>
> --
> Repository URL: http://hg.python.org/cpython
>
> ___
> Python-checkins mailing list
> [email protected]
> http://mail.python.org/mailman/listinfo/python-checkins
>



-- 
Thanks,
Andrew Svetlov
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com


[Python-Dev] Edits to Metadata 1.2 to add extras (optional dependencies)

2012-08-15 Thread Daniel Holth
I've drafted some edits to Metadata 1.2 with valuable feedback from
distutils-sig (special thanks to Erik Bray), which seems to have no
more comments on the issue after about 6 weeks. Let me know if you
have an opinion, or if you will have one during some bounded time in
the future.

Metadata 1.2 (PEP 345), a non-final PEP that has been adopted by
approximately 10 of the latest sdists from pypy, cannot represent the
setuptools "extras" (optional dependencies) feature. This is a problem
because about 1600+ or 10% of the packages hosted on pypy define
"extras" as measured in May of this year.

The edit implements the extras feature by adding a new condition
"extra == 'name'" to the Metadata 1.2 environment markers.
Requirements with this marker are only installed when the named
optional feature is requested. Valid extras for a package must be
declared with Provides-Extra: name.

It also adds Setup-Requires-Dist as a way to specify requirements
needed during an install as opposed to during runtime.


Abbreviated highlights:

Setup-Requires-Dist (multiple use)

Like Requires-Dist, but names dependencies needed while the
distributions's distutils / packaging `setup.py` / `setup.cfg` is run.


Provides-Extra (multiple use)

A string containing the name of an optional feature.

Examples:

Requires-Dist: reportlab; extra == 'pdf'

Requires-Dist: nose; extra == 'test'

Requires-Dist: sphinx; extra == 'doc'


(full changeset on
https://bitbucket.org/dholth/python-peps/changeset/537e83bd4068)

Thanks,

Daniel Holth
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com


Re: [Python-Dev] Edits to Metadata 1.2 to add extras (optional dependencies)

2012-08-15 Thread Eric Snow
On Wed, Aug 15, 2012 at 8:49 AM, Daniel Holth  wrote:
> I've drafted some edits to Metadata 1.2 with valuable feedback from
> distutils-sig (special thanks to Erik Bray), which seems to have no
> more comments on the issue after about 6 weeks. Let me know if you
> have an opinion, or if you will have one during some bounded time in
> the future.
>
> Metadata 1.2 (PEP 345), a non-final PEP that has been adopted by
> approximately 10 of the latest sdists from pypy, cannot represent the
> setuptools "extras" (optional dependencies) feature. This is a problem
> because about 1600+ or 10% of the packages hosted on pypy define
> "extras" as measured in May of this year.
>
> The edit implements the extras feature by adding a new condition
> "extra == 'name'" to the Metadata 1.2 environment markers.
> Requirements with this marker are only installed when the named
> optional feature is requested. Valid extras for a package must be
> declared with Provides-Extra: name.
>
> It also adds Setup-Requires-Dist as a way to specify requirements
> needed during an install as opposed to during runtime.
>
>
> Abbreviated highlights:
>
> Setup-Requires-Dist (multiple use)
>
> Like Requires-Dist, but names dependencies needed while the
> distributions's distutils / packaging `setup.py` / `setup.cfg` is run.
>
>
> Provides-Extra (multiple use)
>
> A string containing the name of an optional feature.
>
> Examples:
>
> Requires-Dist: reportlab; extra == 'pdf'
>
> Requires-Dist: nose; extra == 'test'
>
> Requires-Dist: sphinx; extra == 'doc'
>
>
> (full changeset on
> https://bitbucket.org/dholth/python-peps/changeset/537e83bd4068)

s/pypy/PyPI/

-eric
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com


Re: [Python-Dev] cpython: Add yet another test for subprocess.Popen.communicate

2012-08-15 Thread Antoine Pitrou
On Wed, 15 Aug 2012 21:54:06 +0200 (CEST)
andrew.svetlov  wrote:
> 
> diff --git a/Lib/test/test_subprocess.py b/Lib/test/test_subprocess.py
> --- a/Lib/test/test_subprocess.py
> +++ b/Lib/test/test_subprocess.py
> @@ -645,6 +645,34 @@
>  p.communicate()
>  self.assertEqual(p.returncode, 0)
>  
> +def test_universal_newlines_communicate_stdin_stdout_stderr(self):
> +# universal newlines through communicate(), with only stdin
> +p = subprocess.Popen([sys.executable, "-c",
> +  'import sys,os;' + SETBINARY + '''\nif True:
> +  s = sys.stdin.readline()
> +  sys.stdout.write(s)
> +  sys.stdout.write("line2\\r")
> +  sys.stderr.write("eline2\\n")
> +  s = sys.stdin.read()
> +  sys.stdout.write(s+"line4\\n")
> +  sys.stdout.write(s+"line5\\r\\n")
> +  sys.stderr.write("eline6\\n")
> +  sys.stderr.write("eline7\\r")
> +  sys.stderr.write("eline8\\r\\n")
> +  '''],

This test is wrong. You need to write your test data as binary data on
the binary output streams, as in the other tests. Using the text
output streams introduces a spurious line ending conversion, which makes
the test fail under Windows:
http://buildbot.python.org/all/builders/AMD64%20Windows7%20SP1%203.x/builds/486

> +# Python debug build push something like "[42442 refs]\n"
> +# to stderr at exit of subprocess.
> +
> self.assertTrue(stderr.startswith("eline2\neline6\neline7\neline8\n"))

You should use self.assertStderrEqual() instead.

Regards

Antoine.


-- 
Software development and contracting: http://pro.pitrou.net


___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com