[Python-Dev] updating ensurepip to include wheel

[Nick Coghlan]

On 8 August 2015 at 02:12, Donald Stufft <donald at stufft.io> wrote:
>
>> On Aug 7, 2015, at 11:13 AM, Chris Barker - NOAA Federal <chris.barker at noaa.gov> wrote:
>>
>>> Please don't add extra pain for purity and
>>> make sure that ensurepip installs "pip" and
>>> not "slow pip until you install wheel in the venv".
>>
>>
>> This is a really good point -- other than purity, what is the downside?
>>
>> Arguably, the only reason setuptools, pip, and wheel are not in the
>> standard library are because the need a more rapid development/release
>> cycle.
>>
>> Ensurepip is the way to get the best of both worlds -- why not make it complete?
>>
>
> So my opinion is basically that in a vacuum I would absolutely add wheel to ensurepip (and I did add wheel to get-pip.py and to virtualenv). However, this does not exist in a vacuum and there is still animosity about PEP 453 and downstream’s are still trying to figure out how they are going to handle it for real. During the 3.4 release there were downstream redisttibutors who completely removed ensurepip and were talking about possibly removing pip entirely from their archives.

[I'm wearing my professional Fedora Environments & Stack WG and RHEL
Developer Experience hats in this post, moreso than my CPython core
developer one]

It seems to me that most modern open source developers (especially
those using dynamic languages) perceive Linux distros more as
impediments to be worked around, rather than as allies to collaborate
with, and that's *our* UX issue to figure out downstream (hence design
concepts like https://fedoraproject.org/wiki/Env_and_Stacks/Projects/UserLevelPackageManagement
and https://fedoraproject.org/wiki/Env_and_Stacks/Projects/PackageReviewProcessRedesign
in the Fedora space)

It's not CPython's problem to resolve, and it's only CPython's
responsibility to work around to the extent that it makes things
easier for *end users* developing in Python. If a distro is being
unreasonably intransigent about developer experience concerns, then
that's the distro's problem, and we can advise people to download and
use a cross-platform distro like ActivePython, EPD/Canopy or Anaconda
instead of the system Python.

> So my hesitation is basically that I consider is a short (or medium) term need until pip can implicitly install wheel and setuptools as part of the build process for a particular project and I worry that it will reopen some wounds and cause more strife.

I don't believe it's a good idea to avoid strife for the sake of
avoiding strife - many Linux distros are in the wrong here, and we
need to get with the program in suitably meeting the needs of open
source developers, not just folks running Linux on production servers.
Fedora started that process with the launch of the Fedora.next
initiatives a couple of years ago, but there's still a lot of work to
be done in retooling our online and desktop experience to make it more
developer friendly.

> I do however think it would make ensurepip itself better, so I’m not dead set against it, mostly just worried about ramifications.

I'd advise against letting concerns about Linux distro politics hold
you back from making ensurepip as good as you can make it - if nothing
else, the developer experience folks at commercial Linux vendors are
specifically paid to advocate for the interests of software developers
when it comes to the Linux user experience (that's part of my own day
job in the Fedora/RHEL/CentOS case - I moved over to the software
management team in RHEL Developer Experience at the start of June).

That means that while I will have some *requests* to make certain
things easier downstream (like going through the PEP process to figure
out an upstream supported way to omit the build-only dependencies when
running ensurepip), I also wholeheartedly endorse the idea of having
the default upstream behaviour focus on making the initial experience
for folks downloading Windows or Mac OS X binaries from python.org as
compelling as we can make it. python-dev needs to put the needs of
Python first, and those of Linux second.

This does mean that any Linux distro that can't figure out how to
provide a better open source developer experience for Pythonistas than
Windows or Mac OS X is at risk of falling by the wayside in the Python
community, but if those of us that care specifically about the
viability of desktop Linux as a platform for open source development
stand by and let that happen, then we'll *deserve* the consequences.

Regards,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia