What's your proposed process to arrive at the list of recommended packages?
And is it really just going to be a list of names, or is there going to be
some documentation (about the vetting, not about the contents of the
packages) for each name?
On Mon, Oct 30, 2017 at 9:08 AM, Nick Coghlan <ncogh...@gmail.com> wrote:
> On 31 October 2017 at 00:28, Guido van Rossum <gu...@python.org> wrote:
>
>> 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).
>>
>
> Just because companies are big doesn't mean they necessarily have anyone
> internally that's already up to speed on the specifics of recommended
> practices in a sprawling open source community like Python's. The genesis
> of this idea is that I think we can offer a more consistent initial
> experience for those folks than "Here's PyPI and Google, y'all have fun
> now" (and in so doing, help folks writing books and online tutorials to
> feel more comfortable with the idea of assuming that libraries like
> requests will be available in even the most restrictive institutional
> environments that still allow the use of Python).
>
> One specific situation this idea is designed to help with is the one where:
>
> - there's a centrally managed Standard Operating Environment that dictates
> what gets installed
> - they've approved the python.org installers
> - they *haven't* approved anything else yet
>
> Now, a lot of large orgs simply won't get into that situation in the first
> place, since their own supplier management rules will push them towards a
> commercial redistributor, in which case they'll get their chosen
> redistributor's preferred package set, which will then typically cover at
> least a few hundred of the most popular PyPI packages.
>
> But some of them will start from the narrower "standard library only"
> baseline, and I spent enough time back at Boeing arguing for libraries to
> be added to our approved component list to appreciate the benefits of
> transitive declarations of trust ("we trust supplier X, they unambigously
> state their trust in supplier Y, so that's an additional point in favour of
> our also trusting supplier Y") when it comes time to make your case to your
> supplier management organisation. Such declarations still aren'y always
> sufficient, but they definitely don't hurt, and they sometimes help.
>
> Cheers,
> Nick.
>
> --
> Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
>
--
--Guido van Rossum (python.org/~guido)
_______________________________________________
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/
