-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Am 25.09.13 23:33, schrieb Donald Stufft:
An early draft of this did not have the backport to 2.7 and when I
showed *that* version around to get feedback people were less
enthusiastic about it and generally viewed it as nice but
worthless to me
On Sep 30, 2013, at 5:01 AM, Martin v. Löwis mar...@v.loewis.de wrote:
Signed PGP part
Am 25.09.13 23:33, schrieb Donald Stufft:
An early draft of this did not have the backport to 2.7 and when I
showed *that* version around to get feedback people were less
enthusiastic about it and
On 30 Sep 2013 19:03, Martin v. Löwis mar...@v.loewis.de wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Am 25.09.13 23:33, schrieb Donald Stufft:
An early draft of this did not have the backport to 2.7 and when I
showed *that* version around to get feedback people were less
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Am 30.09.13 13:18, schrieb Donald Stufft:
Well the point we tried to get across in the PEP is that a normal
feature you can typically just install a backport from PyPI to gain
it early. This isin't so much driven by well it'd be nice for the
On 30 Sep 2013 21:52, Martin v. Löwis mar...@v.loewis.de wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Am 30.09.13 13:18, schrieb Donald Stufft:
Well the point we tried to get across in the PEP is that a normal
feature you can typically just install a backport from PyPI to gain
On Sep 30, 2013, at 11:07 PM, Nick Coghlan wrote:
My plan now is to split the PEP in two, so the 3.4 changes can be accepted
as non-controversial, including the offer of core dev assistance in
creating and maintaining a Windows installer for pip to better support
earlier versions. The backporting
Splitting into two pieces also means you can implement it for 3.4
first and identify possible problems caused by preexisting pip
installs before deciding whether to add it to 2.7 and 3.3.
Skip
___
Python-Dev mailing list
Python-Dev@python.org
On 1 October 2013 00:35, Skip Montanaro s...@pobox.com wrote:
Splitting into two pieces also means you can implement it for 3.4
first and identify possible problems caused by preexisting pip
installs before deciding whether to add it to 2.7 and 3.3.
One of the key reasons for using the
On 28 Sep 2013 14:12, Donald Stufft don...@stufft.io wrote:
On Sep 27, 2013, at 11:48 PM, Stephen J. Turnbull step...@xemacs.org
wrote:
Nick Coghlan writes:
You have confirmed my belief that your model is incorrect.
*shrug* I just think the risks are higher than acknowledged (just
In article
CAP1=2W44X6+zaQ9=-J4SdekUJ0CxWy7b8YYk=eWM=88codb...@mail.gmail.com,
Brett Cannon br...@python.org wrote:
On Fri, Sep 27, 2013 at 5:16 PM, Zachary Ware
zachary.ware+py...@gmail.comwrote:
The way I read Terry's proposal, it is to never add the _ensurepip
*module*, but to use (or
On Sep 28, 2013, at 12:48 PM, Stephen J. Turnbull wrote:
*shrug* I just think the risks are higher than acknowledged (just
because you have so far failed to imagine a problem doesn't mean it
won't appear), and that the meta effect that Even Guido admits that
Python 3 isn't ready for prime time
Nick Coghlan writes:
I'm not sure what usage model you're assuming for _ensurepip, but it
appears to be wrong. End users should be able to just run pip, and
either have it work, or else get a message from the OS vendor telling
them to install the appropriate system package.
I don't
On 27 September 2013 15:08, Stephen J. Turnbull step...@xemacs.org wrote:
New users on Windows and Mac OS X. I've heard many more complaints
from folks running tutorials about the pip bootstrapping process than
I ever have from the community at large about the GIL :P
I bet those users are
On 27/09/2013 15:26, Paul Moore wrote:
So, for Windows users, installing a package becomes pip install XXX.
Apologies if this has already been said but it only works if you've
already installed an appropriate compiler. I've lost count of the
number of times I've tried this, got the
On Sep 27, 2013, at 10:39 AM, Mark Lawrence breamore...@yahoo.co.uk wrote:
Apologies if this has already been said but it only works if you've already
installed an appropriate compiler. I've lost count of the number of times
I've tried this, got the (rather cyptic) error: Unable to find
On 27 September 2013 15:39, Mark Lawrence breamore...@yahoo.co.uk wrote:
On 27/09/2013 15:26, Paul Moore wrote:
So, for Windows users, installing a package becomes pip install XXX.
Apologies if this has already been said but it only works if you've already
installed an appropriate compiler.
On Fri, 27 Sep 2013 15:26:41 +0100, Paul Moore p.f.mo...@gmail.com wrote:
On 27 September 2013 15:08, Stephen J. Turnbull step...@xemacs.org wrote:
New users on Windows and Mac OS X. I've heard many more complaints
from folks running tutorials about the pip bootstrapping process than
I
On Fri, Sep 27, 2013 at 12:15 PM, R. David Murray rdmur...@bitdance.com wrote:
On Fri, 27 Sep 2013 15:26:41 +0100, Paul Moore p.f.mo...@gmail.com wrote:
On 27 September 2013 15:08, Stephen J. Turnbull step...@xemacs.org wrote:
New users on Windows and Mac OS X. I've heard many more complaints
Paul Moore writes:
I can't speak for Linux distros or OSX users, but for Windows I do
believe that this is a significant improvement,
Nobody doubts this.
and worth the (IMO, negligible) risk involved in adding this to a
maintenance release.
Doesn't that argument apply equally well to
On Sep 23, 2013, at 7:15 AM, Nick Coghlan ncogh...@gmail.com wrote:
With the last round of updates, I believe PEP 453 is ready for
Martin's pronouncement.
Personally, I'm very excited and happy that this or something like it
is coming close to fruition.
My experiences in userland suggest
On Sep 27, 2013, at 2:14 PM, Stephen J. Turnbull step...@xemacs.org wrote:
Also, I think that proponents of backporting this PEP are missing
something important. Specifically, why are we encouraging the use of
Python 2.7 for new users? Shouldn't we use this as an opportunity
to say, Move
On Fri, Sep 27, 2013 at 11:22 AM, Donald Stufft don...@stufft.io wrote:
On Sep 27, 2013, at 2:14 PM, Stephen J. Turnbull step...@xemacs.org
wrote:
Also, I think that proponents of backporting this PEP are missing
something important. Specifically, why are we encouraging the use of
On 9/27/2013 10:26 AM, Paul Moore wrote:
[snip longish post]
I want to summarize the main points of what I believe Paul said and
strongly agree with them.
* For this issue, and especially for backporting to 2.7/3.3, we should
consider Windows, Mac, and *nix distributions as separate cases.
On Sep 27, 2013, at 2:50 PM, Terry Reedy tjre...@udel.edu wrote:
I add: for 2.7/3.3, there is consequently no need for _ensurepip to be in
/Lib after installation, even if temporarily added*. If it is not there,
there is no change the the stdlib, and hence no violation of the 'no new
On 9/27/2013 3:10 PM, Donald Stufft wrote:
On Sep 27, 2013, at 2:50 PM, Terry Reedy tjre...@udel.edu wrote:
I add: for 2.7/3.3, there is consequently no need for _ensurepip to be in /Lib
after installation, even if temporarily added*. If it is not there, there is no
change the the stdlib,
On Sep 27, 2013, at 4:09 PM, Terry Reedy tjre...@udel.edu wrote:
On 9/27/2013 3:10 PM, Donald Stufft wrote:
On Sep 27, 2013, at 2:50 PM, Terry Reedy tjre...@udel.edu wrote:
I add: for 2.7/3.3, there is consequently no need for _ensurepip to be in
/Lib after installation, even if
On Fri, Sep 27, 2013 at 3:29 PM, Donald Stufft don...@stufft.io wrote:
snip
If it lives in the source tree how are you going to provent it from existing
when someone installs on Linux? OSX? One of the BSDs?
If someone is building their own Python from source--regardless of
platform--they're
On Sep 26, 2013, at 02:30 PM, Nick Coghlan wrote:
- the module name should be _ensurepip in all versions
- the PEP should explicitly state that the don't remove _ensurepip
and it's wheel files caveat for redistributors applies only in 3.4+
(where removing it will break pyvenv)
I'm sorry that I
On 28 Sep 2013 00:08, Stephen J. Turnbull step...@xemacs.org wrote:
Nick Coghlan writes:
I'm not sure what usage model you're assuming for _ensurepip, but it
appears to be wrong. End users should be able to just run pip, and
either have it work, or else get a message from the OS vendor
2013/9/27 Barry Warsaw ba...@python.org:
On Sep 26, 2013, at 02:30 PM, Nick Coghlan wrote:
- the module name should be _ensurepip in all versions
- the PEP should explicitly state that the don't remove _ensurepip
and it's wheel files caveat for redistributors applies only in 3.4+
(where removing
On Fri, Sep 27, 2013 at 5:16 PM, Zachary Ware
zachary.ware+py...@gmail.comwrote:
On Fri, Sep 27, 2013 at 3:29 PM, Donald Stufft don...@stufft.io wrote:
snip
If it lives in the source tree how are you going to provent it from
existing when someone installs on Linux? OSX? One of the BSDs?
On Sep 27, 2013, at 9:20 PM, Brett Cannon br...@python.org wrote:
On Fri, Sep 27, 2013 at 5:16 PM, Zachary Ware zachary.ware+py...@gmail.com
wrote:
On Fri, Sep 27, 2013 at 3:29 PM, Donald Stufft don...@stufft.io wrote:
snip
If it lives in the source tree how are you going to
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 09/27/2013 10:50 PM, Donald Stufft wrote:
On Sep 27, 2013, at 9:20 PM, Brett Cannon br...@python.org
mailto:br...@python.org wrote:
On Fri, Sep 27, 2013 at 5:16 PM, Zachary Ware
zachary.ware+py...@gmail.com
Nick Coghlan writes:
You have confirmed my belief that your model is incorrect.
*shrug* I just think the risks are higher than acknowledged (just
because you have so far failed to imagine a problem doesn't mean it
won't appear), and that the meta effect that Even Guido admits that
Python 3
On Sep 27, 2013, at 11:48 PM, Stephen J. Turnbull step...@xemacs.org wrote:
Nick Coghlan writes:
You have confirmed my belief that your model is incorrect.
*shrug* I just think the risks are higher than acknowledged (just
because you have so far failed to imagine a problem doesn't mean
On Wed, 25 Sep 2013 19:15:05 -0400
Barry Warsaw ba...@python.org wrote:
On Sep 25, 2013, at 07:08 PM, Donald Stufft wrote:
On Sep 25, 2013, at 7:04 PM, Barry Warsaw ba...@python.org wrote:
So, why shouldn't we add enum to the Python 2.7 stdlib?
Because with PEP453 you can just ``pip
On Wed, Sep 25, 2013 at 7:15 PM, Donald Stufft don...@stufft.io wrote:
On Sep 25, 2013, at 7:04 PM, Barry Warsaw ba...@python.org wrote:
Another reason to oppose this is what I've heard quite often from people
regarding Python 2.7. I've been told that many folks are actually really
Le Thu, 26 Sep 2013 14:54:49 +1000,
Nick Coghlan ncogh...@gmail.com a écrit :
On 26 September 2013 14:30, Nick Coghlan ncogh...@gmail.com wrote:
That said, there are changes that I think are definitely worth
making due to the concerns you raise:
- the module name should be _ensurepip in
Ideally people won't be typing either of them because it'll be installed
automatically. They might in some cases (accidentally uninstalled pip?)
I agree that it seems there is paranoia going on here and that the risk is low
and making it just be a special cased new feature is ok. However the
Le Thu, 26 Sep 2013 10:22:55 -0400,
Donald Stufft don...@stufft.io a écrit :
Ideally people won't be typing either of them because it'll be
installed automatically. They might in some cases (accidentally
uninstalled pip?)
Installing from source perhaps.
I agree that it seems there is
On Sep 26, 2013, at 10:28 AM, Antoine Pitrou solip...@pitrou.net wrote:
Le Thu, 26 Sep 2013 10:22:55 -0400,
Donald Stufft don...@stufft.io a écrit :
Ideally people won't be typing either of them because it'll be
installed automatically. They might in some cases (accidentally
uninstalled
On 27 Sep 2013 00:12, Antoine Pitrou solip...@pitrou.net wrote:
Le Thu, 26 Sep 2013 14:54:49 +1000,
Nick Coghlan ncogh...@gmail.com a écrit :
On 26 September 2013 14:30, Nick Coghlan ncogh...@gmail.com wrote:
That said, there are changes that I think are definitely worth
making due to
On Sep 23, 2013, at 09:15 PM, Nick Coghlan wrote:
With the last round of updates, I believe PEP 453 is ready for
Martin's pronouncement.
I want to raise an objection to PEP's proposal to add this as a new feature to
Python 2.7 and 3.3. I understand the rationale as stated here:
On Wed, 25 Sep 2013 16:50:22 -0400
Barry Warsaw ba...@python.org wrote:
On Sep 23, 2013, at 09:15 PM, Nick Coghlan wrote:
With the last round of updates, I believe PEP 453 is ready for
Martin's pronouncement.
I want to raise an objection to PEP's proposal to add this as a new feature to
On 26 Sep 2013 06:53, Barry Warsaw ba...@python.org wrote:
On Sep 23, 2013, at 09:15 PM, Nick Coghlan wrote:
With the last round of updates, I believe PEP 453 is ready for
Martin's pronouncement.
I want to raise an objection to PEP's proposal to add this as a new
feature to
Python 2.7 and
On Sep 25, 2013, at 4:50 PM, Barry Warsaw ba...@python.org wrote:
Why does it have to be added to the source tree for stable releases?
I think it should be placed in the source tree for the stable releases. The
reasoning is that 2.7 is going to stick around for a long time. Immediately
this
On Sep 25, 2013, at 05:33 PM, Donald Stufft wrote:
I think it should be placed in the source tree for the stable releases. The
reasoning is that 2.7 is going to stick around for a long time. Immediately
this won't be ubiquitous but as time goes on you'll be able to be ensured
that a ``python -m
On Sep 26, 2013, at 07:14 AM, Nick Coghlan wrote:
On 26 Sep 2013 06:53, Barry Warsaw ba...@python.org wrote:
Why does it have to be added to the source tree for stable releases?
If it can get into the installers another way, it doesn't, really. It only
needs to be in the source tree for 3.4+.
On Sep 25, 2013, at 5:51 PM, Barry Warsaw ba...@python.org wrote:
On Sep 25, 2013, at 05:33 PM, Donald Stufft wrote:
I think it should be placed in the source tree for the stable releases. The
reasoning is that 2.7 is going to stick around for a long time. Immediately
this won't be
On 26 Sep 2013 07:54, Barry Warsaw ba...@python.org wrote:
On Sep 25, 2013, at 05:33 PM, Donald Stufft wrote:
I think it should be placed in the source tree for the stable releases.
The
reasoning is that 2.7 is going to stick around for a long time.
Immediately
this won't be ubiquitous but
On Sep 25, 2013, at 06:15 PM, Donald Stufft wrote:
Well I don't think many scripts will be executing ensurepip, maybe i'm wrong,
but yes it does mean that not all Python 2.7's are alike. Most likely though
at some point 2.7.XXX is going to be near standard as the 2.7 hold outs stay
on it and time
On Sep 25, 2013, at 7:04 PM, Barry Warsaw ba...@python.org wrote:
So, why shouldn't we add enum to the Python 2.7 stdlib? Or any other new
feature? Just be aware that if this PEP is accepted for Python 2.7, the bar
will be set much lower for other Really Useful Features That Make Users
On Sep 26, 2013, at 09:01 AM, Nick Coghlan wrote:
Would a leading underscore in the module name make you more comfortable
with the idea? It's really intended mostly as a hidden implementation
detail of the installers and pyvenv anyway, so calling it _ensurepip
would help make that explicit while
On Sep 25, 2013, at 7:04 PM, Barry Warsaw ba...@python.org wrote:
Another reason to oppose this is what I've heard quite often from people
regarding Python 2.7. I've been told that many folks are actually really
happy with using 2.7 precisely because it extremely stable. They don't have
to
On Sep 25, 2013, at 07:08 PM, Donald Stufft wrote:
On Sep 25, 2013, at 7:04 PM, Barry Warsaw ba...@python.org wrote:
So, why shouldn't we add enum to the Python 2.7 stdlib?
Because with PEP453 you can just ``pip install enum34`` it :)
Of course, pip messing with global Python state on a
On Sep 25, 2013, at 7:15 PM, Barry Warsaw ba...@python.org wrote:
Of course, pip messing with global Python state on a package managed system
like most Linux distros, is a whole 'nuther happy fun ball of killer
beeswax. :)
mixing-metaphors-ly y'rs,
-Barry
virtualenv invocation not shown
Donald Stufft writes:
On Sep 25, 2013, at 7:04 PM, Barry Warsaw ba...@python.org wrote:
So, why shouldn't we add enum to the Python 2.7 stdlib? Or any
other new feature? Just be aware that if this PEP is accepted
for Python 2.7, the bar will be set much lower for other Really
On 26 September 2013 09:08, Barry Warsaw ba...@python.org wrote:
On Sep 26, 2013, at 09:01 AM, Nick Coghlan wrote:
Would a leading underscore in the module name make you more comfortable
with the idea? It's really intended mostly as a hidden implementation
detail of the installers and pyvenv
On 26 September 2013 11:52, Stephen J. Turnbull step...@xemacs.org wrote:
Donald Stufft writes:
On Sep 25, 2013, at 7:04 PM, Barry Warsaw ba...@python.org wrote:
So, why shouldn't we add enum to the Python 2.7 stdlib? Or any
other new feature? Just be aware that if this PEP is
On 26 September 2013 14:30, Nick Coghlan ncogh...@gmail.com wrote:
That said, there are changes that I think are definitely worth making
due to the concerns you raise:
- the module name should be _ensurepip in all versions
- the PEP should explicitly state that the don't remove _ensurepip
On 24 September 2013 09:34, Ned Deily n...@acm.org wrote:
In general, I think this is a very important usability feature and I
am in favor of the general approach. Good work, all! I do have some
comments, primarily about items that are not currently addressed.
Your reply and Barry's suggest
With the last round of updates, I believe PEP 453 is ready for
Martin's pronouncement.
HTML: http://www.python.org/dev/peps/pep-0453/
Major diffs: http://hg.python.org/peps/rev/b2993450b32a
Many of the updates are just clarifications in response to questions,
but the actual significant changes
In general, I think this is a very important usability feature and I
am in favor of the general approach. Good work, all! I do have some
comments, primarily about items that are not currently addressed.
``ensurepip`` itself (including the private copy of ``pip`` and its
dependencies) will
On Sep 23, 2013, at 7:34 PM, Ned Deily n...@acm.org wrote:
One final comment is that the PEP does not go into any detail on how it
will be implemented. As it stands, there is a fair amount of one-time
work, including implementing ensurepip, changes to the Windows installer,
changes to the
On Sep 23, 2013, at 7:34 PM, Ned Deily n...@acm.org wrote:
In general, I think this is a very important usability feature and I
am in favor of the general approach. Good work, all! I do have some
comments, primarily about items that are not currently addressed.
``ensurepip`` itself
On Sep 23, 2013, at 8:12 PM, Donald Stufft don...@stufft.io wrote:
A common source of Python installations are through downstream distributors
such as the various Linux Distributions [#ubuntu]_ [#debian]_ [#fedora]_,
OSX
package managers [#homebrew]_, or Python-specific tools [#conda]_.
In article 44f4e1f8-5533-45a7-810e-b9c13530e...@stufft.io,
Donald Stufft don...@stufft.io wrote:
On Sep 23, 2013, at 7:34 PM, Ned Deily n...@acm.org wrote:
[... license implications ...]
As far as I know the certificate bundle is licensed under either GPL, MPL,
or LGPL. However there is
On Sep 24, 2013, at 12:32 AM, Ned Deily n...@acm.org wrote:
IANAL, but I think it would be good if, at least, the setuptools license were
clearer and the LGPL reference for the cert bundle was changed. It *might*
be
a good idea to get an opinion from Van Lindberg. But I'm happy to defer
68 matches
Mail list logo
