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.

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