<p dir="ltr"><br>
On 18 Jul 2013 09:37, "Vinay Sajip" <<a href="mailto:vinay_sajip@yahoo.co.uk">vinay_sajip@yahoo.co.uk</a>> wrote:<br>
><br>
> Nick Coghlan <ncoghlan <at> <a href="http://gmail.com">gmail.com</a>> writes:<br>
><br>
> > Technically the decision *hasn't* been made - there is, as yet, no<br>
> bundling PEP for me to consider for any installer, and I've decided not to<br>
> accept Richard's bootstrapping PEP due to the issues around delaying the<br>
> download to first use. I'd just like to have a bundling PEP posted before I<br>
> make that official, so I can refer to it in the rejection notice.<br>
><br>
> Technically? Well, "that ship has sailed" seems pretty well decided to me. I<br>
> know that "technically is the best kind of correct" :-)<br>
><br>
> But IIUC, your reservations on PEP 439 (I didn't realise that was what<br>
> Donald was referring to in his response) related to Richard's specific<br>
> implementation. I posted an example getpip.py (very simple, I grant you)<br>
> which would get setuptools and pip for users, without the need for bundling<br>
> anything, plus proposed an equivalent upgrade for pyvenv which would do the<br>
> same for venvs. There has been no discussion around getpip.py whatsoever,<br>
> AFAIK.<br>
><br>
> > However, even without a PEP, I consider pip the only acceptable option, as<br>
> I believe we have no credibility left to burn with the broader Python<br>
> development community on tool choices. We've spent years telling everyone<br>
><br>
> We don't need to burn any credibility at all. Perhaps python-dev lost some<br>
> credibility when packaging got pulled from 3.3, even though it was a good<br>
> decision made for the right reasons. But you only ask people to believe you<br>
> when you have some new story to tell them, and pip is hardly new.<br>
><br>
> > We're now telling people, OK setuptools is actually fine, but you should<br>
> still use pip instead of easy_install and start using wheels instead of<br>
> eggs. This is defensible, since even people using distribute were still<br>
> importing setuptools.<br>
><br>
> This is something which arose from the coming together of setuptools and<br>
> Distribute. There was no credibility lost promoting Distribute, since<br>
> setuptools never supported Python 3 - until now. There's no credibility lost<br>
> now promoting setuptools, since it is essentially now the same as Distribute<br>
> without the need for compatibility workarounds.<br>
><br>
> > However, I simply see *no way* we could pull off a migration to a new<br>
> recommended installer when the migration from the previous one to the<br>
> current one is still far from complete :P<br>
><br>
> I'm certainly not suggesting the time is right for migrating to a new<br>
> recommended installer we have always promoted pip (over easy_install), and<br>
> that doesn't need to change. It doesn't mean we have to bundle pip with<br>
> Python - just make it easier to get it on Windows and OS X. Just a few days<br>
> ago you were saying that python -m getpip would be good to have, then I<br>
> created a getpip module, and now AFAICT it hasn't even been looked at, while<br>
> people gear up to do shed-loads of work to bundle pip with Python.<br>
><br>
> > Adding in the distutils2/packaging digression just lowers our collective<br>
> credibility even further, and we also get some significant spillover from<br>
> the Python 3 transition.<br>
><br>
> Haters gonna hate. What're you gonna do? :-)</p>
<p dir="ltr">It's not about haters - it's about not causing additional pain for people that we have already asked to put up with a lot. However solid our reasons for doing so were, we've deliberately created a bunch of additional work for various people.<br>
</p>
<p dir="ltr">><br>
> > Essentially, don't underestimate how thin the ice we're currently walking<br>
> on is community-wise: people are irritated and even outright angry with the<br>
> Python core development team, and they have good reasons to be. We need to<br>
> remain mindful of that, and take it into account when deciding how to<br>
> proceed.<br>
><br>
> Who are these angry, entitled people? Have they forgotten that Python is a<br>
> volunteer project? Why do we owe such people anything? I'm not convinced<br>
> that such people are representative of the wider community.</p>
<p dir="ltr">I'm talking about people who don't get mad, they just walk away. Or they even stick around, grin, and bear it without complaint. They matter, even if they don't complain.</p>
<p dir="ltr">We have a duty of care to our users to find the least disruptive path forward (that's why Python 3 was such a big deal - we chose the disruptive path because we couldn't see any other solution).</p>
<p dir="ltr">In the case of packaging, that means finding a way to let educators and Python developers safely assume that end users, experienced or otherwise, will have ready access to the pip CLI.</p>
<p dir="ltr">Cheers,<br>
Nick. <br></p>
<p dir="ltr">><br>
> To judge from the video of the packaging panel at PyCon 2013, people are<br>
> perhaps disappointed that we haven't got further, but there was no animosity<br>
> that I could detect. The atmosphere was pretty positive and what I saw was<br>
> an endearing faith and hope that we would, in time, get things right.<br>
><br>
> None of what you have said answers why the PEP process shouldn't be followed<br>
> in this case. No compelling case has been made AFAICT for bundling pip as<br>
> opposed to enabling python -m getpip, especially given that (a) the work<br>
> involved in one is very small compared to the other, and (b) the result for<br>
> the user is the same - they get to use setuptools and pip.<br>
><br>
> Regards,<br>
><br>
> Vinay Sajip<br>
><br>
> _______________________________________________<br>
> Distutils-SIG maillist  -  <a href="mailto:Distutils-SIG@python.org">Distutils-SIG@python.org</a><br>
> <a href="http://mail.python.org/mailman/listinfo/distutils-sig">http://mail.python.org/mailman/listinfo/distutils-sig</a><br>
</p>