On 18 Jul 2013 09:37, "Vinay Sajip" <vinay_sa...@yahoo.co.uk> wrote: > > Nick Coghlan <ncoghlan <at> gmail.com> writes: > > > Technically the decision *hasn't* been made - there is, as yet, no > bundling PEP for me to consider for any installer, and I've decided not to > accept Richard's bootstrapping PEP due to the issues around delaying the > download to first use. I'd just like to have a bundling PEP posted before I > make that official, so I can refer to it in the rejection notice. > > Technically? Well, "that ship has sailed" seems pretty well decided to me. I > know that "technically is the best kind of correct" :-) > > But IIUC, your reservations on PEP 439 (I didn't realise that was what > Donald was referring to in his response) related to Richard's specific > implementation. I posted an example getpip.py (very simple, I grant you) > which would get setuptools and pip for users, without the need for bundling > anything, plus proposed an equivalent upgrade for pyvenv which would do the > same for venvs. There has been no discussion around getpip.py whatsoever, > AFAIK.
No, my reservations are about delaying the installation of pip to first use (or any time after the installation of Python). I don't care that much about the distinction between bundling and install-time bootstrapping and would appreciate a PEP that explicitly weighed up the pros and cons of those two approaches (at the very least bundling means you don't need a reliable network connection at install time, while install time bootstrapping avoids the problem of old versions of pip, and also gives a way to bootstrap older Python installations). Cheers, Nick. > > > However, even without a PEP, I consider pip the only acceptable option, as > I believe we have no credibility left to burn with the broader Python > development community on tool choices. We've spent years telling everyone > > We don't need to burn any credibility at all. Perhaps python-dev lost some > credibility when packaging got pulled from 3.3, even though it was a good > decision made for the right reasons. But you only ask people to believe you > when you have some new story to tell them, and pip is hardly new. > > > We're now telling people, OK setuptools is actually fine, but you should > still use pip instead of easy_install and start using wheels instead of > eggs. This is defensible, since even people using distribute were still > importing setuptools. > > This is something which arose from the coming together of setuptools and > Distribute. There was no credibility lost promoting Distribute, since > setuptools never supported Python 3 - until now. There's no credibility lost > now promoting setuptools, since it is essentially now the same as Distribute > without the need for compatibility workarounds. > > > However, I simply see *no way* we could pull off a migration to a new > recommended installer when the migration from the previous one to the > current one is still far from complete :P > > I'm certainly not suggesting the time is right for migrating to a new > recommended installer we have always promoted pip (over easy_install), and > that doesn't need to change. It doesn't mean we have to bundle pip with > Python - just make it easier to get it on Windows and OS X. Just a few days > ago you were saying that python -m getpip would be good to have, then I > created a getpip module, and now AFAICT it hasn't even been looked at, while > people gear up to do shed-loads of work to bundle pip with Python. > > > Adding in the distutils2/packaging digression just lowers our collective > credibility even further, and we also get some significant spillover from > the Python 3 transition. > > Haters gonna hate. What're you gonna do? :-) > > > Essentially, don't underestimate how thin the ice we're currently walking > on is community-wise: people are irritated and even outright angry with the > Python core development team, and they have good reasons to be. We need to > remain mindful of that, and take it into account when deciding how to > proceed. > > Who are these angry, entitled people? Have they forgotten that Python is a > volunteer project? Why do we owe such people anything? I'm not convinced > that such people are representative of the wider community. > > To judge from the video of the packaging panel at PyCon 2013, people are > perhaps disappointed that we haven't got further, but there was no animosity > that I could detect. The atmosphere was pretty positive and what I saw was > an endearing faith and hope that we would, in time, get things right. > > None of what you have said answers why the PEP process shouldn't be followed > in this case. No compelling case has been made AFAICT for bundling pip as > opposed to enabling python -m getpip, especially given that (a) the work > involved in one is very small compared to the other, and (b) the result for > the user is the same - they get to use setuptools and pip. > > Regards, > > Vinay Sajip > > _______________________________________________ > 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
