Re: [Distutils] PEP 439 and pip bootstrap updated
On 10 July 2013 05:19, Carl Meyer c...@oddbird.net 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 anything in it. One other problem I have, personally, with pyvenv, is that the activate code for powershell is significantly less user-friendly than that in virtualenv. Add to that the fact that the Python release cycle is significantly slower than that of virtualenv, and using dev versions of Python is far less practical for day to day use, and that's why I stick to virtualenv at the moment (that and the pip point mentioned already). I really ought to post a patch for Python to upgrade the activate script to use the one from virtualenv. Are there any licensing/ownership issues that might make this problematic? For example, the script is signed and I don't know if that signature is attributable to someone specific... Paul ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] PEP 439 and pip bootstrap updated
Richard Jones r1chardj0n3s at gmail.com writes: pip without virtualenv in python 2 contexts is pretty rare (or at least *should* be wink) 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? I agree with Donald's suggestion that virtualenv *not* be included, or are you saying that you want to include it for those users who have 3.4 *and* 2.x installed? If you include virtualenv, it makes it possible for people to mistakenly use it even though the recommended approach is to use the built-in venv support in Python. Exactly what benefit does including virtualenv provide in a 3.4+ installation? Regards, Vinay Sajip ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] PEP 439 and pip bootstrap updated
Carl Meyer carl at 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://gist.github.com/vsajip/4673395 Of course, that'll now need to be changed to install setuptools rather than distribute :-) Regards, Vinay Sajip ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] PEP 439 and pip bootstrap updated
On 10 July 2013 18:28, Tres Seaver tsea...@palladion.com 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.python.org/dev/peps/pep-0405/ Environments generated by pyvenv lack setuptools, which makes them un-useful compared to those generated by virtualenv. Yes, but Python 3.4 will have the pip bootstrap which automatically installs setuptools. Unless you mean that pyvenv itself (sans pip) would be more useful with setuptools? Virtualenv is also useful across the important set of Python versions (2.6, 2.7, 3.2, 3.3), which pyvenv (or any shipped-in-core varieant) can never be. Yes, that's why I suggested the Python 2 version will install virtualenv :-) There's currently no plan to release a Python 3.3 version of the bootstrap, and certainly not one for a Py3k version lower than that. Hm. We can think about it though. Richard ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] PEP 439 and pip bootstrap updated
On 10 July 2013 19:08, Vinay Sajip vinay_sa...@yahoo.co.uk wrote: Richard Jones r1chardj0n3s at gmail.com writes: pip without virtualenv in python 2 contexts is pretty rare (or at least *should* be wink) 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? 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). Exactly what benefit does including virtualenv provide in a 3.4+ installation? That was kinda my question wink Richard ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] PEP 439 and pip bootstrap updated
Richard Jones richard at 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+ context. The PEP states Hereafter the installation of the 'pip implementation' will imply installation of setuptools and virtualenv. and, a few lines further down, The bootstrap process will proceed as follows: 1. The user system has Python (3.4+) installed. I don't see any mention of backporting this bootstrap to 2.x. Exactly what benefit does including virtualenv provide in a 3.4+ installation? That was kinda my question wink Sorry, it didn't come across like a question, more like a fait accompli :-) Regards, Vinay Sajip ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] PEP 439 and pip bootstrap updated
On 10 July 2013 19:55, Vinay Sajip vinay_sa...@yahoo.co.uk wrote: Richard Jones richard at 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+ context. The PEP states Hereafter the installation of the 'pip implementation' will imply installation of setuptools and virtualenv. Sorry I've not made this clearer. Per the discussion here I've removed that from the PEP. That version hasn't been built on the web server yet. Exactly what benefit does including virtualenv provide in a 3.4+ installation? That was kinda my question wink Sorry, it didn't come across like a question, more like a fait accompli :-) Poorly phrased, my apologies. Richard ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] PEP 439 and pip bootstrap updated
On Wed, Jul 10, 2013 at 12:54 AM, Richard Jones rich...@python.org wrote: On 10 July 2013 14:19, Carl Meyer c...@oddbird.net 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 is ever ported to 2.7 or 3.2, it would make sense for it to install virtualenv there (or, probably even better, for pyvenv to be backported along with the bootstrap). I intend to create two forks; one for consideration in a 2.7.5 release as pip and the other for users of 2.6+ called get-pip.py. Why the specific shift between 2.7 and 2.6 in terms of naming? I realize you are differentiating between the bootstrap being pre-installed with Python vs. not, but is there really anything wrong with the script being called pip (or pip3 for Python 3.3/3.2) if it knows how to do the right thing to get pip up and going? IOW why not make the bootstrap what everyone uses to install pip and it just so happens to come pre-installed with Python 3.4 (and maybe Python 2.7)? ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] PEP 439 and pip bootstrap updated
On 10 July 2013 13:46, Brett Cannon br...@python.org 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 I'm not happy with that - specifically because the *existing* pip is not called pip3. 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. 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, and even if there were, I would not want to use it, I'm happy with the unsuffixed version). I appreciate that Unix users have different compatibility priorities here, but can I propose that on Windows at least, the bootstrap command is pip and that matches the core pip that will be downloaded? Oh - and one other thing, on Windows python is often not on the system PATH - that's what the py.exe launcher is for. So where will the pip bootstrap command be installed, and where will it install the real pip? And also, will the venv code be modified to install the pip bootstrap in the venv's Scripts directory? Does virtualenv need to change to do the same? What if pip has already been bootstrapped in the system Python? Maybe I need to properly review the PEP rather than just throwing out random thoughts :-) Paul ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] PEP 439 and pip bootstrap updated
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 get-pip, rerun the original install command On Jul 10, 2013, at 8:46 AM, Brett Cannon br...@python.org wrote: On Wed, Jul 10, 2013 at 12:54 AM, Richard Jones rich...@python.org wrote: On 10 July 2013 14:19, Carl Meyer c...@oddbird.net 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 is ever ported to 2.7 or 3.2, it would make sense for it to install virtualenv there (or, probably even better, for pyvenv to be backported along with the bootstrap). I intend to create two forks; one for consideration in a 2.7.5 release as pip and the other for users of 2.6+ called get-pip.py. Why the specific shift between 2.7 and 2.6 in terms of naming? I realize you are differentiating between the bootstrap being pre-installed with Python vs. not, but is there really anything wrong with the script being called pip (or pip3 for Python 3.3/3.2) if it knows how to do the right thing to get pip up and going? IOW why not make the bootstrap what everyone uses to install pip and it just so happens to come pre-installed with Python 3.4 (and maybe Python 2.7)? ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] PEP 439 and pip bootstrap updated
On Wed, Jul 10, 2013 at 9:43 AM, Paul Moore p.f.mo...@gmail.com wrote: On 10 July 2013 13:46, Brett Cannon br...@python.org 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 I'm not happy with that - specifically because the *existing* pip is not called pip3. 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. But you should be typing python3 here, not python (and PEP 394 is trying to get people to start using python2 as the name to invoke). 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, and even if there were, I would not want to use it, I'm happy with the unsuffixed version). As Donald pointed out, you would always use pip3. The bootstrapping aspect is a behind-the-scenes thing; just consider the script as launch pip if installed, else, bootstrap it in and then launch it. I appreciate that Unix users have different compatibility priorities here, but can I propose that on Windows at least, the bootstrap command is pip and that matches the core pip that will be downloaded? There won't be a difference in command-line usage. Oh - and one other thing, on Windows python is often not on the system PATH - that's what the py.exe launcher is for. So where will the pip bootstrap command be installed, and where will it install the real pip? Covered in the PEP: it will go into the user installation location as if --user had been specified. And also, will the venv code be modified to install the pip bootstrap in the venv's Scripts directory? In the PEP: goes into the venv. Does virtualenv need to change to do the same? What if pip has already been bootstrapped in the system Python? Then nothing special happens; the script just executes pip instead of triggering a bootstrap first. Maybe I need to properly review the PEP rather than just throwing out random thoughts :-) I feel like I just fed a bad habit. =) ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] PEP 439 and pip bootstrap updated
On 10 Jul, 2013, at 11:40, Richard Jones rich...@python.org wrote: On 10 July 2013 19:08, Vinay Sajip vinay_sa...@yahoo.co.uk wrote: Richard Jones r1chardj0n3s at gmail.com writes: pip without virtualenv in python 2 contexts is pretty rare (or at least *should* be wink) 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? 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). New features in a bugfix release? You better hope the RM doesn't hear :-) That said, 2.7 will be around for a while and adding a consistent installation experience to both 3.4 and 2.7 does sound attractive and adding a new script shouldn't have that many side effects. What about backporting pyvenv as well? I guess that's way too invasive for a bugfix release. Ronald ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] PEP 439 and pip bootstrap updated
On Wed, Jul 10, 2013 at 12:37 AM, Richard Jones r1chardj0...@gmail.com wrote: pip without virtualenv in python 2 contexts is pretty rare (or at least *should* be wink) 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 experience that a lot of people in the scientific community, for example, do not use virtualenv (sometimes with good reasons, but more often not). Erik ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] PEP 439 and pip bootstrap updated
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, and even if there were, I would not want to use it, I'm happy with the unsuffixed version). I have a lot of sympathy for this, and the general issue has come up in a number of different contexts, e.g. nostests/nosetests3 and so on. On a distro like Debian, this just adds more gunk to /usr/bin, especially since some scripts are also minor-version dependent. One approach is to use `$python -m nose` or in this case `$python -m pip` which cuts down on the number of scripts, is unambiguous, but is far from convenient and may not work in all cases, e.g. for older Python's that don't support -m or don't support it for packages. I think there was a thread on python-ideas about this, but in the back of my mind, I have this horrible idea for a version-aware relauncher you could use in your shebang line. Something like: #! /usr/bin/pylaunch So that you could do something like: $ nosetests -3 $ nosetests -2 $ nosetests -3.3 $ nosetests -2.7 and it would relaunch itself using the correct Python version, consuming the version argument so the actual script wouldn't see it. I'm not sure if the convenience is worth it, and I'm sorry for making you throw up a little in your mouth there. -Barry signature.asc Description: PGP signature ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] PEP 439 and pip bootstrap updated
On Wed, Jul 10, 2013 at 12:11 PM, Paul Moore p.f.mo...@gmail.com wrote: On 10 July 2013 15:28, Brett Cannon br...@python.org 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. But you should be typing python3 here, not python (and PEP 394 is trying to get people to start using python2 as the name to invoke). So - that's a major behaviour change on Windows. At the moment, Python 3.3 for Windows installs python.exe and pythonw.exe. There are no versioned executables at all. Are you saying that in 3.4 this will change? That will break so many things I have to believe you're wrong or I've misunderstood you. OTOH, adding python3.exe and python3w.exe (or is that pythonw3.exe?) which I can then ignore is fine by me (but in that case, the change doesn't affect my point about the pip command). Didn't know Windows was never updated to use a versioned binary. That's rather unfortunate. -Brett As I say, I understand Unix is different. This is a purely Windows point - and in the context of the PEP, that's what I'm saying, please can we be careful to be clear whether the plan is for the new pip bootstrap to favour existing platform conventions or uniformity (with the further complication of needing to consider the full pip distribution's behaviour - and there, I will be lobbying hard against any change to require a pip3 command to be used, at least on Windows). As things stand, I can assume the PEP specifies Unix behaviour and is vague or silent on Windows variations, or I can ask for clarification, and for the results to be documented in the PEP. Up to now I was doing the former, but I'm moving towards the latter - hence my question(s). ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] PEP 439 and pip bootstrap updated
On 11 Jul 2013 04:56, Brett Cannon br...@python.org wrote: On Wed, Jul 10, 2013 at 12:11 PM, Paul Moore p.f.mo...@gmail.com wrote: On 10 July 2013 15:28, Brett Cannon br...@python.org 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. But you should be typing python3 here, not python (and PEP 394 is trying to get people to start using python2 as the name to invoke). So - that's a major behaviour change on Windows. At the moment, Python 3.3 for Windows installs python.exe and pythonw.exe. There are no versioned executables at all. Are you saying that in 3.4 this will change? That will break so many things I have to believe you're wrong or I've misunderstood you. OTOH, adding python3.exe and python3w.exe (or is that pythonw3.exe?) which I can then ignore is fine by me (but in that case, the change doesn't affect my point about the pip command). 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. For Windows, we likely need to consider something based on py -m pip, which then raises the question of whether or not that's what we should be supporting on *nix as well (with pip and pip3 as convenient shorthand). There's also the fact that the Python launcher is *already* available as a separate Windows installer for earlier releases. Perhaps we should just be bundling the bootstrap script with that for earlier Windows releases. Cheers, Nick. -Brett As I say, I understand Unix is different. This is a purely Windows point - and in the context of the PEP, that's what I'm saying, please can we be careful to be clear whether the plan is for the new pip bootstrap to favour existing platform conventions or uniformity (with the further complication of needing to consider the full pip distribution's behaviour - and there, I will be lobbying hard against any change to require a pip3 command to be used, at least on Windows). As things stand, I can assume the PEP specifies Unix behaviour and is vague or silent on Windows variations, or I can ask for clarification, and for the results to be documented in the PEP. Up to now I was doing the former, but I'm moving towards the latter - hence my question(s). ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] PEP 439 and pip bootstrap updated
On 10 July 2013 21:30, Nick Coghlan ncogh...@gmail.com wrote: On 11 Jul 2013 04:56, Brett Cannon br...@python.org 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. For Windows, we likely need to consider something based on py -m pip, which then raises the question of whether or not that's what we should be supporting on *nix as well (with pip and pip3 as convenient shorthand). There's also the fact that the Python launcher is *already* available as a separate Windows installer for earlier releases. Perhaps we should just be bundling the bootstrap script with that for earlier Windows releases. Thanks Nick. I was part way through a much more laboured email basically saying the same thing :-) For reference, PEP 394 is the versioned binary PEP. It is explicitly Unix only and defers Windows to PEP 397 (pylauncher) as being too complex to cover alongside the Unix proposal :-) 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 it bypasses all the issues around versioned executables, cross-platform issues, the general dreadfulness of script wrappers on Windows, etc, in one fell swoop. Paul. ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] PEP 439 and pip bootstrap updated
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 that it bypasses all the issues around versioned executables, cross-platform issues, the general dreadfulness of script wrappers on Windows, etc, in one fell swoop. +1 -Barry signature.asc Description: PGP signature ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] PEP 439 and pip bootstrap updated
On Jul 10, 2013, at 5:39 PM, Barry Warsaw ba...@python.org 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 lukewarm about the -m interface, but its key advantage is that it bypasses all the issues around versioned executables, cross-platform issues, the general dreadfulness of script wrappers on Windows, etc, in one fell swoop. +1 -Barry ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig As long as the non -m way exists so I don't have to use it D: - Donald Stufft PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA signature.asc Description: Message signed with OpenPGP using GPGMail ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] PEP 439 and pip bootstrap updated
On 10 July 2013 23:00, Donald Stufft don...@stufft.io 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 they want). It'll be nice seeing Unix be the non-standard one for a change :-) Paul ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] PEP 439 and pip bootstrap updated
On 11 July 2013 06:50, Paul Moore p.f.mo...@gmail.com 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 it bypasses all the issues around versioned executables, cross-platform issues, the general dreadfulness of script wrappers on Windows, etc, in one fell swoop. python -m pip does make the bootstrapping a more complex proposition - the stdlib would have to have something called pip that could be overridden (while it is actually *running*) by something installed in site-packages. Not easy. Thanks everyone for your brilliant feedback and discussion - I look forward to being able to say something sensible about Windows in the PEP :-) Richard ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
