On 8 August 2015 at 02:12, Donald Stufft <donald@stufft.io> wrote:
On Aug 7, 2015, at 11:13 AM, Chris Barker - NOAA Federal <chris.barker@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/UserLevelPackageManag... and https://fedoraproject.org/wiki/Env_and_Stacks/Projects/PackageReviewProcessR... 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@gmail.com | Brisbane, Australia