[Python-ideas] More "ensure*" packages

[Steve Dower]

On 13Aug2015 1450, Donald Stufft wrote:
> 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.

Agreed, but that sort of endorsement needs to be handled very very 
carefully.

>
>>
>> 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.

Yes, but if the aim is to lighten the stdlib, then installing the 
heavier stdlib into its usual place would make the transition easier. 
Not a huge concern right now though.

>
>>
>> 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.

We could, but I don't want to, mainly to avoid the "which version am I 
on" problem.

What I want is for the question to be "do I have the latest version" and 
the answer to be "pip install -U ...". I would also insist that 
something like requests should do that on initial install anyway, so you 
only get the bundled version if you install offline.

> 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.

Obviously by becoming a downstream redistributor you no longer affect 
the other downstream redistributors (unless they see you as competition, 
which is more of a concern on Windows where distros generally don't have 
platform lock-in).

> 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.

Maybe this should just be a Windows (and maybe Mac) only thing then. 
Distros that provide python3-requests (and maybe eventually 
python3-tkinter/idle) can choose to make that a default install if they 
like, so upstream doesn't need to cover it, but until a distro becomes 
more popular than the python.org release we won't see that on Windows. 
The tcl/tk dependency is also most blatant on Windows as well, since we 
apparently depend on the system's version on every other platform.

Cheers,
Steve

> -----------------
> Donald Stufft
> PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA
>
>
> _______________________________________________
> Python-ideas mailing list
> Python-ideas at python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/
>