[Python-ideas] Defining an easily installable "Recommended baseline package set"

[Guido van Rossum]

I just feel that when you're talking about an org like PayPal they can take
care of themselves and don't need our help. They will likely have packages
they want installed everywhere that would never make in on your list. So it
feels this whole discussion is a distraction and a waste of time (yours,
too).

On Sun, Oct 29, 2017 at 10:24 PM, Nick Coghlan <ncoghlan at gmail.com> wrote:

> On 30 October 2017 at 04:56, Guido van Rossum <guido at 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 at gmail.com   |   Brisbane, Australia
>



-- 
--Guido van Rossum (python.org/~guido)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20171030/670f0f9a/attachment-0001.html>