On Jul 13, 2013, at 8:12 AM, Vinay Sajip wrote:
> I'm not aware of this - have you published any protocols around the work
> you're doing on warehouse, which Nick said was going to be the
> next-generation PyPI?
I think we're talking past each other at this point but I wanted to respond to
t
On 13 July 2013 13:12, Vinay Sajip wrote:
> I'll just finish by re-iterating that I think there should be some stdlib
> underpinning for packaging in general, and that there should be some focus
> on exactly what that underpinning should be, and that I'm by no means
> saying that distlib is it. I
> From: Donald Stufft
>As I said in my email, because it's more or less standalone and it has the
>greatest utility outside of installers/builders/archivers/indexes.
Even if that were true, it doesn't mean that it's the *only* thing that's worth
considering.
>I've looked at many other l
On 13 July 2013 01:02, Donald Stufft wrote:
> >> The installer side of things the purist side of me doesn't like adding
> it to
> >> the standard library for all the same reasons but the pragmatic side of
> me
> >> wants it there because it enables fetching the other bits that are
> needed for
>
On 13 July 2013 05:25, Brett Cannon wrote:
>
> On Fri, Jul 12, 2013 at 2:16 PM, Donald Stufft wrote:
>
>>
>> On Jul 12, 2013, at 2:00 PM, Brett Cannon wrote:
>>
>> Speaking with my python-dev hat on which has a badge from when I led the
>> stdlib cleanup for Python 3, I would say anything that
On Jul 12, 2013, at 7:14 PM, Vinay Sajip wrote:
> Donald Stufft stufft.io> writes:
>
>> I could probably be convinced about something that makes handling versions
>> easier going into the standard lib, but that's about it.
>
> That seems completely arbitrary to me. Why just versions? Why not,
Donald Stufft stufft.io> writes:
> I could probably be convinced about something that makes handling versions
> easier going into the standard lib, but that's about it.
That seems completely arbitrary to me. Why just versions? Why not, for
example, support for the wheel format? Why not agreed me
On Jul 12, 2013, at 3:25 PM, Brett Cannon wrote:
>
>
>
> On Fri, Jul 12, 2013 at 2:16 PM, Donald Stufft wrote:
>
> On Jul 12, 2013, at 2:00 PM, Brett Cannon wrote:
>
>> Speaking with my python-dev hat on which has a badge from when I led the
>> stdlib cleanup for Python 3, I would say an
On Fri, Jul 12, 2013 at 2:16 PM, Donald Stufft wrote:
>
> On Jul 12, 2013, at 2:00 PM, Brett Cannon wrote:
>
> Speaking with my python-dev hat on which has a badge from when I led the
> stdlib cleanup for Python 3, I would say anything that has a PEP should
> probably have a module in the stdlib
On Jul 12, 2013, at 2:00 PM, Brett Cannon wrote:
> Speaking with my python-dev hat on which has a badge from when I led the
> stdlib cleanup for Python 3, I would say anything that has a PEP should
> probably have a module in the stdlib for it. That way standard management of
> whatever is sp
Donald Stufft stufft.io> writes:
> Maybe I misunderstood your point :) I thought you were saying that by
> installing pip using setup.py install we are "blessing" setup.py install
> again? I was saying we don't need to do that.
Okay, I see. I'm used to comments referring to points directly above
On Fri, Jul 12, 2013 at 12:16 PM, Vinay Sajip wrote:
> Donald Stufft stufft.io> writes:
>
> > I'm also against adding distlib-like functionality to the stdlib. At
> least at
> > this point in time. We've seen the far reaching effects that adding a
> > packaging lib directly to the stdlib can have
Donald Stufft stufft.io> writes:
> Yes it's a goal to get rid of setup.py install, but I doubt it will ever
> fully be gone. At least not for a long time. There's almost 150k source
> dist packages on PyPI and I'm going to assume the vast bulk of them have
> a setup.py.
True, but distil seems to
On Jul 12, 2013, at 1:28 PM, Vinay Sajip wrote:
> Daniel Holth gmail.com> writes:
>
>> Getting rid of an executable build script is no longer a goal. Builds
>> inherently need that often. But we don't want people extending distutils
>> against their will.
>
> Perhaps I should have been cleare
Daniel Holth gmail.com> writes:
> Getting rid of an executable build script is no longer a goal. Builds
> inherently need that often. But we don't want people extending distutils
> against their will.
Perhaps I should have been clearer - I meant "executable setup.py install",
and as I understand
On Jul 12, 2013, at 1:10 PM, Vinay Sajip wrote:
> Donald Stufft stufft.io> writes:
>
>> Eh, installing a pure Python Wheel is pretty simple. Especially if you
>> restrict the options it can have. I don't see any reason why the bootstrap
>> script can't include that as an internal implementatio
The goal is that it will be equally easy to install packages built with any
build system. We are on our way.
Getting rid of an executable build script is no longer a goal. Builds
inherently need that often. But we don't want people extending distutils
against their will.
On Jul 12, 2013 11:59 AM,
Donald Stufft stufft.io> writes:
> Eh, installing a pure Python Wheel is pretty simple. Especially if you
> restrict the options it can have. I don't see any reason why the bootstrap
> script can't include that as an internal implementation detail.
Sorry, I don't understand what you mean here, i
On 12 July 2013 16:17, Donald Stufft wrote:
> There's very little reason why a pip bootstrap script couldn't unpack a
> wheel instead of using setup.py. Infact I've advocated for this and plan on
> contributing a bare bones wheel installation routine that would work well
> enough to get pip and s
On Jul 12, 2013, at 12:16 PM, Vinay Sajip wrote:
> Donald Stufft stufft.io> writes:
>
>> I'm also against adding distlib-like functionality to the stdlib. At least at
>> this point in time. We've seen the far reaching effects that adding a
>> packaging lib directly to the stdlib can have. I do
Donald Stufft stufft.io> writes:
> I prefer the implicit bootstrap approach, but if the explicit bootstrap
> approach is chosen then something special needs to be done for pyvenv.
The original pyvenv script did install Distribute and pip, but that
functionality was removed before beta because D
Donald Stufft stufft.io> writes:
> I'm also against adding distlib-like functionality to the stdlib. At least at
> this point in time. We've seen the far reaching effects that adding a
> packaging lib directly to the stdlib can have. I don't want to see us repeat
> the mistakes of the past and ad
Nick Coghlan gmail.com> writes:
> Some day pip will get a "wheel only" mode, and that's the step that will kill
> off the need to run setup.py on production machines even when using the
> Python specific tools.
> Blessing both setuptools and pip as the "obvious way to do it" is designed to
> giv
On Jul 12, 2013, at 1:19 AM, Nick Coghlan wrote:
> On 12 July 2013 15:11, Nick Coghlan wrote:
> In particular, it establishes the infrastructure to have pyvenv automatically
> bootstrap the installer into each venv, even when it isn't installed system
> wide (which is the key missing feature
On Jul 12, 2013, at 4:35 AM, Vinay Sajip wrote:
> The current situation, as I see it, is a transitional one. When distlib-like
> functionality becomes available in the stdlib, other approaches will be
> possible, which improve upon what's possible with setuptools and pip. I've
> demonstrated som
On Fri, Jul 12, 2013 at 4:35 AM, Vinay Sajip wrote:
> Donald Stufft stufft.io> writes:
>
> > We should remember that in general people have considered PyEnv that
> ships
> > with Python 3.3 an inferior alternative to virtualenv largely in part
> > because they have to fetch setuptools and pip pri
On 12 Jul 2013 18:36, "Vinay Sajip" wrote:
>
> Donald Stufft stufft.io> writes:
>
> > We should remember that in general people have considered PyEnv that
ships
> > with Python 3.3 an inferior alternative to virtualenv largely in part
> > because they have to fetch setuptools and pip prior to usi
Donald Stufft stufft.io> writes:
> We should remember that in general people have considered PyEnv that ships
> with Python 3.3 an inferior alternative to virtualenv largely in part
> because they have to fetch setuptools and pip prior to using it whereas in
> virtualenv they do not.
Let's remem
On 12 July 2013 15:11, Nick Coghlan wrote:
> In particular, it establishes the infrastructure to have pyvenv
> automatically bootstrap the installer into each venv, even when it isn't
> installed system wide (which is the key missing feature of pyvenv relative
> to virtualenv).
>
The other thing
On 12 July 2013 12:12, Richard Jones wrote:
> The point of PEP 439 is that the current situation of "but first do
> this" for any given 3rd-party package installation was a bad thing and
> we desire to move away from it. The PEP therefore proposes to allow
> "just do this" to eventually become th
On Jul 11, 2013, at 10:12 PM, Richard Jones wrote:
> The point of PEP 439 is that the current situation of "but first do
> this" for any given 3rd-party package installation was a bad thing and
> we desire to move away from it. The PEP therefore proposes to allow
> "just do this" to eventually b
The point of PEP 439 is that the current situation of "but first do
this" for any given 3rd-party package installation was a bad thing and
we desire to move away from it. The PEP therefore proposes to allow
"just do this" to eventually become the narrative. The direction this
conversation is headin
Daniel Holth gmail.com> writes:
> I hope we will also arrive at a pip that doesn't need to be individually
> installed per venv...
You mean, like distil? :-)
Regards,
Vinay Sajip
___
Distutils-SIG maillist - Distutils-SIG@python.org
http://mail.py
I hope we will also arrive at a pip that doesn't need to be individually
installed per venv...
On Jul 11, 2013 6:13 PM, "Paul Moore" wrote:
> +1 Explicit is better than implicit.
>
> Amending venv to automatically install pip (as suggested by Donald) may be
> worth doing. I'm +0 on that (with the
+1 Explicit is better than implicit.
Amending venv to automatically install pip (as suggested by Donald) may be
worth doing. I'm +0 on that (with the proviso that there's a --no-pip
option in that case). OTOH, the venv module is very extensible and writing
your own wrapper to import getpip and cal
On Jul 11, 2013, at 6:00 PM, Carl Meyer wrote:
> On 07/11/2013 03:48 PM, Nick Coghlan wrote:
>> I was thinking about that, and I'm wondering if the most sensible option
>> may be to claim the "getpip" name on PyPI for ourselves and then do the
>> following:
>>
>> 1. Provide "getpip" in the stan
On 07/11/2013 03:48 PM, Nick Coghlan wrote:
> I was thinking about that, and I'm wondering if the most sensible option
> may be to claim the "getpip" name on PyPI for ourselves and then do the
> following:
>
> 1. Provide "getpip" in the standard library for 3.4+ (and perhaps in a
> 2.7.x release)
+1. No magic side effects will make everyone happier.
On Jul 11, 2013 5:48 PM, "Nick Coghlan" wrote:
> (Oops, started this yesterday, got distracted and never hit send)
>
> On 11 July 2013 11:09, Richard Jones wrote:
> >
> > On 11 July 2013 06:50, Paul Moore wrote:
> > > I think "python -m pip"
(Oops, started this yesterday, got distracted and never hit send)
On 11 July 2013 11:09, Richard Jones wrote:
>
> On 11 July 2013 06:50, Paul Moore wrote:
> > I think "python -m pip" should be the canonical form (used in
documentation,
> > examples, etc). The unittest module has taken this route
On 11 July 2013 18:05, PJ Eby wrote:
> On Thu, Jul 11, 2013 at 10:20 AM, Brett Cannon wrote:
> > And if people want to promote the -m option then the executable scripts
> just
> > become a secondary convenience. Plus you can't exactly require
> setuptools to
> > create those scripts at install-t
On Thu, Jul 11, 2013 at 10:20 AM, Brett Cannon wrote:
> And if people want to promote the -m option then the executable scripts just
> become a secondary convenience. Plus you can't exactly require setuptools to
> create those scripts at install-time with Python if that's when they are
> going to
On Jul 11, 2013, at 11:50 AM, Brett Cannon wrote:
> Yes, but you can clear it out of sys.modules before executing runpy to get
> the desired effect of falling through to the regular package (runpy wouldn't
> import pip.__main__ so you literally just need ``del sys.modules['pip']``).
> You cou
On Thu, Jul 11, 2013 at 10:52 AM, Donald Stufft wrote:
>
> On Jul 11, 2013, at 10:47 AM, Brett Cannon wrote:
>
> I'm just not seeing the downside. We control the stdlib and pip, so we
> know the expected interaction and we are purposefully using the override
> mechanics so it's not going to get
On Thu, Jul 11, 2013 at 11:50 AM, Brett Cannon wrote:
>
>
>
> On Thu, Jul 11, 2013 at 10:52 AM, Donald Stufft wrote:
>
>>
>> On Jul 11, 2013, at 10:47 AM, Brett Cannon wrote:
>>
>> I'm just not seeing the downside. We control the stdlib and pip, so we
>> know the expected interaction and we are
On Jul 11, 2013, at 10:47 AM, Brett Cannon wrote:
> I'm just not seeing the downside. We control the stdlib and pip, so we know
> the expected interaction and we are purposefully using the override mechanics
> so it's not going to get messed up by us if we consciously use it (and
> obviously
On Thu, Jul 11, 2013 at 10:29 AM, Daniel Holth wrote:
> On Thu, Jul 11, 2013 at 9:33 AM, Paul Moore wrote:
> > On 11 July 2013 13:49, Brett Cannon wrote:
> >>
> >> The dead-simple, extremely elegant solution (starting in Python 3.4) is
> to
> >> make pip a namespace package in the stdlib with n
On Thu, Jul 11, 2013 at 9:33 AM, Paul Moore wrote:
> On 11 July 2013 13:49, Brett Cannon wrote:
>>
>> The dead-simple, extremely elegant solution (starting in Python 3.4) is to
>> make pip a namespace package in the stdlib with nothing more than a
>> __main__.py file that installs pip; no checkin
On Thu, Jul 11, 2013 at 9:39 AM, Donald Stufft wrote:
>
> On Jul 11, 2013, at 9:33 AM, Paul Moore wrote:
>
> The pip executable script/wrapper currently uses setuptools entry points
> and wrapper scripts. I'm not a fan of those, so I'd be happy to see the
> change you suggest, but OTOH they have
On Jul 11, 2013, at 9:33 AM, Paul Moore wrote:
> The pip executable script/wrapper currently uses setuptools entry points and
> wrapper scripts. I'm not a fan of those, so I'd be happy to see the change
> you suggest, but OTOH they have been like that since long before I was
> involved with p
On 11 July 2013 13:49, Brett Cannon wrote:
> The dead-simple, extremely elegant solution (starting in Python 3.4) is to
> make pip a namespace package in the stdlib with nothing more than a
> __main__.py file that installs pip; no checking if it's installed and then
> running it, etc, just blindl
On Wed, Jul 10, 2013 at 9:09 PM, Richard Jones wrote:
> On 11 July 2013 06:50, Paul Moore wrote:
> > I think "python -m pip" should be the canonical form (used in
> documentation,
> > examples, etc). The unittest module has taken this route, as has timeit.
> > Traditionally, python-dev have been
On 11 July 2013 06:50, Paul Moore wrote:
> I think "python -m pip" should be the canonical form (used in documentation,
> examples, etc). The unittest module has taken this route, as has timeit.
> Traditionally, python-dev have been lukewarm about the -m interface, but its
> key advantage is that
On 10 July 2013 23:00, Donald Stufft wrote:
> As long as the non -m way exists so I don't have to use it D:
Fair enough :-)
Having a standard method (-m) and a platform-specific Unix method seems
fine to me (and the Unix people can debate the merits of pip3 vs pip etc as
much or as little as t
On Jul 10, 2013, at 5:39 PM, Barry Warsaw wrote:
> On Jul 10, 2013, at 09:50 PM, Paul Moore wrote:
>
>> I think "python -m pip" should be the canonical form (used in
>> documentation, examples, etc). The unittest module has taken this route, as
>> has timeit. Traditionally, python-dev have been
On Jul 10, 2013, at 09:50 PM, Paul Moore wrote:
>I think "python -m pip" should be the canonical form (used in
>documentation, examples, etc). The unittest module has taken this route, as
>has timeit. Traditionally, python-dev have been lukewarm about the -m
>interface, but its key advantage is th
On 10 July 2013 21:30, Nick Coghlan wrote:
>
> On 11 Jul 2013 04:56, "Brett Cannon" wrote:
> >
> > Didn't know Windows was never updated to use a versioned binary. That's
> rather unfortunate.
>
> Hence the PyLauncher project.
>
> Paul's right, though - the PEP is currently very *nix-centric. Fo
On 11 Jul 2013 04:56, "Brett Cannon" wrote:
>
>
>
>
> On Wed, Jul 10, 2013 at 12:11 PM, Paul Moore wrote:
>>
>> On 10 July 2013 15:28, Brett Cannon wrote:
So, at present, if I (as a 100% Python 3 user) want to install a
package, I type "pip install XXX". No version suffix. In the same
On Wed, Jul 10, 2013 at 12:11 PM, Paul Moore wrote:
> On 10 July 2013 15:28, Brett Cannon wrote:
>
>> So, at present, if I (as a 100% Python 3 user) want to install a package,
>>> I type "pip install XXX". No version suffix. In the same way, to invoke
>>> Python, I type "py" (I'm on Windows here
On 10 July 2013 15:28, Brett Cannon wrote:
> So, at present, if I (as a 100% Python 3 user) want to install a package,
>> I type "pip install XXX". No version suffix. In the same way, to invoke
>> Python, I type "py" (I'm on Windows here) or if I want the currently active
>> virtualenv, "python".
On Jul 10, 2013, at 02:43 PM, Paul Moore wrote:
>I would find it distinctly irritating if in Python 3.4 I have to type "pip3
>bootstrap" to bootstrap pip - and even worse if *after* the bootstrap the
>command I use is still "pip". (And no, there is currently no "pip3" command
>installed by pip, an
On Wed, Jul 10, 2013 at 12:37 AM, Richard Jones wrote:
> pip without virtualenv in python 2 contexts is pretty rare (or at
> least *should* be ) so I think I'll retain it in that bootstrap
> code.
I agree it *should* be rare in most cases but it most assuredly is
not. I can tell you from experie
On 10 Jul, 2013, at 11:40, Richard Jones wrote:
> On 10 July 2013 19:08, Vinay Sajip wrote:
>> Richard Jones gmail.com> writes:
>>
>>> pip without virtualenv in python 2 contexts is pretty rare (or at
>>> least *should* be ) so I think I'll retain it in that bootstrap
>>> code.
>>
>> Perhaps
On Wed, Jul 10, 2013 at 9:43 AM, Paul Moore wrote:
> On 10 July 2013 13:46, Brett Cannon wrote:
>
>> pip (or pip3 for Python 3.3/3.2)
>
>
> Sorry to butt in here, but can I just catch this point. There seems to be
> an ongoing series of assumptions over whether the bootstrap is called pip
> or p
When bundled the script is supposed to mask the fact you don't have pip
installed.
Basically if you type pip3 install requests it will first install setuptools
and pip and then pass the command into the real pip. If it was called get pip
then the workflow would be "attempt to install", "run ge
On 10 July 2013 13:46, Brett Cannon wrote:
> pip (or pip3 for Python 3.3/3.2)
Sorry to butt in here, but can I just catch this point. There seems to be
an ongoing series of assumptions over whether the bootstrap is called pip
or pip3. The pep actually says the bootstrap will be called pip3, but
On Wed, Jul 10, 2013 at 12:54 AM, Richard Jones wrote:
> On 10 July 2013 14:19, Carl Meyer wrote:
> > They certainly do today, but that's primarily because pyvenv isn't very
> > useful yet, since the stdlib has no installer and thus a newly-created
> > pyvenv has no way to install anything in it
On 10 July 2013 19:55, Vinay Sajip wrote:
> Richard Jones python.org> writes:
>
>> It makes sense to me (and Nick) to simplify the packaging overhead for
>> users of Python 2. Currently the story is a bit of a mess (multiple
>> sites with different approaches).
>
> No argument there, but I still
Richard Jones python.org> writes:
> It makes sense to me (and Nick) to simplify the packaging overhead for
> users of Python 2. Currently the story is a bit of a mess (multiple
> sites with different approaches).
No argument there, but I still don't see the relevance of virtualenv in a
3.4+ cont
On 10 July 2013 19:08, Vinay Sajip wrote:
> Richard Jones gmail.com> writes:
>
>> pip without virtualenv in python 2 contexts is pretty rare (or at
>> least *should* be ) so I think I'll retain it in that bootstrap
>> code.
>
> Perhaps I misunderstand, but what's the relevance of Python 2 context
On 10 July 2013 18:28, Tres Seaver wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On 07/09/2013 11:20 PM, Donald Stufft wrote:
>
>> doesn't "PyEnv" which is bundled with Python 3.3+ replace virtualenv?
>> What's the purpose of including virtualenv in the bootstrap?
>> http://www.pyth
Carl Meyer oddbird.net> writes:
> They certainly do today, but that's primarily because pyvenv isn't very
> useful yet, since the stdlib has no installer and thus a newly-created
> pyvenv has no way to install anything in it.
True, though I've provided a script to do that very thing:
https://gi
Richard Jones gmail.com> writes:
> pip without virtualenv in python 2 contexts is pretty rare (or at
> least *should* be ) so I think I'll retain it in that bootstrap
> code.
Perhaps I misunderstand, but what's the relevance of Python 2 contexts here?
Aren't we talking about Python 3.4 and later
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 07/09/2013 11:20 PM, Donald Stufft wrote:
> doesn't "PyEnv" which is bundled with Python 3.3+ replace virtualenv?
> What's the purpose of including virtualenv in the bootstrap?
> http://www.python.org/dev/peps/pep-0405/
Environments generated by
On 10 July 2013 05:19, Carl Meyer wrote:
> > It's my understanding that people still install virtualenv in py3k.
>
> They certainly do today, but that's primarily because pyvenv isn't very
> useful yet, since the stdlib has no installer and thus a newly-created
> pyvenv has no way to install anyt
On 10 July 2013 14:19, Carl Meyer wrote:
> They certainly do today, but that's primarily because pyvenv isn't very
> useful yet, since the stdlib has no installer and thus a newly-created
> pyvenv has no way to install anything in it.
Ah, thanks for clarifying that.
> Certainly if the bootstrap
Hi Richard,
On 07/09/2013 09:47 PM, Richard Jones wrote:
> On 10 July 2013 13:20, Donald Stufft wrote:
>> On Jul 9, 2013, at 11:16 PM, Richard Jones wrote:
>> Firstly, I've just made some additional changes to PEP 439 to include:
>>
>> - installing virtualenv as well (so now pip, setuptools and
On Jul 10, 2013, at 12:37 AM, Richard Jones wrote:
> On 10 July 2013 14:18, Donald Stufft wrote:
>> On Jul 9, 2013, at 11:47 PM, Richard Jones wrote:
>>> On 10 July 2013 13:20, Donald Stufft wrote:
On Jul 9, 2013, at 11:16 PM, Richard Jones wrote:
Firstly, I've just made some addit
On 10 July 2013 14:18, Donald Stufft wrote:
> On Jul 9, 2013, at 11:47 PM, Richard Jones wrote:
>> On 10 July 2013 13:20, Donald Stufft wrote:
>>> On Jul 9, 2013, at 11:16 PM, Richard Jones wrote:
>>> Firstly, I've just made some additional changes to PEP 439 to include:
>>>
>>> - installing vi
On Jul 9, 2013, at 11:47 PM, Richard Jones wrote:
> On 10 July 2013 13:20, Donald Stufft wrote:
>> On Jul 9, 2013, at 11:16 PM, Richard Jones wrote:
>> Firstly, I've just made some additional changes to PEP 439 to include:
>>
>> - installing virtualenv as well (so now pip, setuptools and virt
On 10 July 2013 13:20, Donald Stufft wrote:
> On Jul 9, 2013, at 11:16 PM, Richard Jones wrote:
> Firstly, I've just made some additional changes to PEP 439 to include:
>
> - installing virtualenv as well (so now pip, setuptools and virtualenv are
> installed)
>
>
> doesn't "PyEnv" which is bund
On Jul 9, 2013, at 11:16 PM, Richard Jones wrote:
> [firstly, my apologies for posting the announcement yesterday of the pip
> bootstrap implementation and PEP updates to the pypa-dev list instead of
> distutils-sig... I blame PyCon AU exhaustion :-)]
>
> Firstly, I've just made some addition
[firstly, my apologies for posting the announcement yesterday of the pip
bootstrap implementation and PEP updates to the pypa-dev list instead of
distutils-sig... I blame PyCon AU exhaustion :-)]
Firstly, I've just made some additional changes to PEP 439 to include:
- installing virtualenv as wel
82 matches
Mail list logo
