[Distutils] Q about best practices now (or near future)

[Vinay Sajip]

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? :-)

> 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