[Python-ideas] More "ensure*" packages

[Donald Stufft]

On August 13, 2015 at 5:29:15 PM, Steve Dower (steve.dower at python.org) wrote:
>  
> It's already a fairly crowded marketplace, at least on Windows.
> Anaconda, Canopy, WinPython, Pythonxy and Portable Python all come to
> mind, but none of them have reliably replaced the official Python
> installer. In large part, I suspect this is because they do too much -
> most include the scipy stack and at least one (typically 4-5) editors.

I think that’s also discounting the *huge* benefit of something being offered as the official Python thing. I think a lot of people are hesitant to install those other things because they come someone else, or they aren’t even aware of them because they searched for Python on google and got the official installer.

>  
> What might be interesting is if we installed the meta-package into the
> Lib directory rather than Lib/site-packages. That also opens up the
> possibility of removing old/deprecated modules from the stdlib but
> having an install option to restore them. Which helps break up the
> stdlib a bit and make the core Python install lighter, but still isn't
> really suitable for something like requests.

Right, I don’t think it’s suitable at all to install something that is typically installed from PyPI into anything other than Lib/site-packages.

>  
> I also don't see any real gain in making it a separate thing from the
> main installer unless you're planning 10+ packages to be in there. I
> would expect an incredibly small amount of packages to be available -
> those with no significant competitors, extremely broad uses, and
> completely portable.
>  

Can we release new, different, installers for say, a hypothetical 3.5.0 without cutting a new release of 3.5.0 that include updated versions of the bundled software? If so, how will people know they are using the latest version of that installer? I know that requests will not be very happy being bundled like that if getting a new version is tied to a new version of Python being released.

This is one of the primary benefits of a separate installer, the installer (really the set of things that get installed) gets a version number. You can release it independently of a Python release, so if requests has a security issue then you can just roll out a new version of the platform installer without that affecting Python at all. 

Another major benefit of a separate installer that layers ontop of Python is reducing (or eliminating) the friction it will cause with downstream redistributors. The “sort of stdlib, sort of not” status of pip is weird and has caused a bit of a problem. I’m still dealing with the fallout of that, and while we had to do it that way in order for it to work inside of virtual environments, I don’t think we need to do this that way.

I also think the separation just makes way more sense, when you have ensure* it means that things like python-pip depend on Python, but then Python also depends on them. I don’t think that Python the runtime needs to depends on requests and I think that doing that is going the wrong way. What this really is, is just a collection of preinstalled packages, so treating it like that seems like a better option.

-----------------
Donald Stufft
PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA