<div dir="ltr">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?<br></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Oct 30, 2017 at 9:08 AM, Nick Coghlan <span dir="ltr"><<a href="mailto:ncoghlan@gmail.com" target="_blank">ncoghlan@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span class="">On 31 October 2017 at 00:28, Guido van Rossum <span dir="ltr"><<a href="mailto:guido@python.org" target="_blank">guido@python.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">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).<br></div></blockquote><div><br></div></span><div>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).<br></div><div><br></div><div>One specific situation this idea is designed to help with is the one where:</div><div><br></div><div>- there's a centrally managed Standard Operating Environment that dictates what gets installed</div><div>- they've approved the <a href="http://python.org" target="_blank">python.org</a> installers</div><div>- they *haven't* approved anything else yet<br></div></div></div><div class="gmail_extra"><br></div><div class="gmail_extra">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.</div><div class="gmail_extra"><br></div><div class="gmail_extra">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.</div><span class=""><div class="gmail_extra"><br></div><div class="gmail_extra">Cheers,</div><div class="gmail_extra">Nick.<br></div><div class="gmail_extra"><br>-- <br><div class="m_5732371379362461412gmail_signature" data-smartmail="gmail_signature">Nick Coghlan   |   <a href="mailto:ncoghlan@gmail.com" target="_blank">ncoghlan@gmail.com</a>   |   Brisbane, Australia</div>
</div></span></div>
</blockquote></div><br><br clear="all"><br>-- <br><div class="gmail_signature" data-smartmail="gmail_signature">--Guido van Rossum (<a href="http://python.org/~guido" target="_blank">python.org/~guido</a>)</div>
</div>