On 18 Jul 2013 09:37, "Vinay Sajip" <vinay_sajip@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.
>
> > 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? :-)

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.

>
> > 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.

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.

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).

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.

Cheers,
Nick.

>
> 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