[Python-ideas] More "ensure*" packages

[Steve Dower]

On 13Aug2015 1348, Donald Stufft wrote:
> On August 13, 2015 at 4:29:11 PM, Steve Dower (steve.dower at python.org) wrote:
>> Didn't see Donald's email, so I'm replying via Alex's reply.
>
> Hopefully you get this, I got some error about SPF last time I sent the email :/

I'm on a new mail server, so it's entirely possible that it's one of my 
settings. Can you forward the full error to me off-list?

>
>>
>> So basically we could add a requirements.txt into the core CPython repo
>> and installers could trigger it (with user permission) on install? We
>> could call it "python-platform.txt", and even add an
>> "ensurepythonplatform" module to run the install (all names are only
>> suggestions).
>>
>> I'd still like to bundle wheels with the latest available versions at
>> build so that non-networked installs can get the packages, if not
>> necessarily the latest. This seems like a better long term approach than
>> one-ensure-module-per-package.
>
>
> Well, I’d probably make the “Python Platform” sort of a super-installer that has inside of it the Python installer and then a requirements.txt or whatever along with whatever bundled wheels it needs. Leave the old Python installers alone and continue to generate them (as a sort of “Minimal” installation option). The benefit to having a super installer over top of the core installers, is that you can update and version this super installer independently of the Python installers, so we could do releases more often, maybe every 3-6 months or so. This would essentially just be pulling in the latest Python version, and the latest versions of each of the bundled libraries. To be clear, the bundled libraries would be bundled into the super installer itself, not into Python.
>
> The idea being, that this is something that gets layered overtop of the “Python Runtime” (aka Python the language and standard library) and doesn’t require anything special or any changes to Python itself. I *think* this will make it easier for downstream redistributors because they could implement this “Python Platform” using just a metapackage and typical dependency information and wouldn’t need to deal with any of the mess that the bundled ensurepip module has created. This metapackage would just depend on Python, and each of the included third party libraries in the platform.
>
> This isn’t really something that python-dev itself would have to do (since it requires no changes to Python itself), however there’s benefit to python-dev doing it both in the official-ness of it, and getting it put onto www.python.org and the documentation. Ideally I think we’d change the downloads to push the Python Platform for installers over the actual Python runtime.

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.

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.

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.

Cheers,
Steve

>
>>
>> I feel like moving tkinter&co onto PyPI is the more controversial
>> suggestion :)
>
> I don’t have an opinion specific to tkinter & co, other than I think a smaller standard library and a larger external ecosystem combined with the platform thing I described above is a better direction to go in. I’ve long wanted such a thing.
>
> -----------------
> 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/
>