On 30 October 2017 at 04:56, Guido van Rossum <guido@python.org> wrote:

The two use cases you describe (scripters and teachers) leave me luke-warm -- scripters live in the wild west and can just pip install whatever (that's what it means to be scripting)

For personal scripting, we can install whatever, but "institutional scripting" isn't the same thing - there we're scripting predefined "Standard Operating Environments", like those Mahmoud Hashemi describes for PayPal at the start of https://www.paypal-engineering.com/2016/09/07/python-packaging-at-paypal/

"Just use PyInstaller" isn't an adequate answer in large-scale environments because of the "zlib problem": you don't want to have to rebuild and redeploy the world to handle a security update in a low level frequently used component, you want to just update that component and have everything else pick it up dynamically.

While "Just use conda" is excellent advice nowadays for any organisation contemplating defining their own bespoke Python SOE (hence Mahmoud's post), if that isn't being driven by the folks that already maintain the SOE (as happened in PayPal's case) convincing an org to add a handful of python-dev endorsed libraries to an established SOE is going to be easier than rebasing their entire Python SOE on conda.

and teachers tend to want a customized bundle anyway -- let the edu world get together and create their own recommended bundle.

As long as it's not going to be bundled, i.e. there's just going to be some list of packages that we recommend to 3rd party repackagers, then I'm fine with it. But they must remain clearly marked as 3rd party packages in whatever docs we provide, and live in site-packages.

Yep, that was my intent, although it may not have been clear in my initial proposal. I've filed two separate RFEs in relation to that:

* Documentation only: https://bugs.python.org/issue31898

* Regression testing resource: https://bugs.python.org/issue31899

Cheers,

Nick.

Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia