On 17 November 2016 at 12:42, Stephen J. Turnbull <turnbull.stephen...@u.tsukuba.ac.jp> wrote: > Cory Benfield writes: > > > I think the core question you need to answer for this proposal is: > > why is “pip install oic” not easy-enough reach? > > My first guess would be "some enterprises use OAuth internally for the > same reason they have draconian approval policies". More > straightforwardly, this is the kind of battery that enterprises which > make it hard to use pip seem likely to value. Nick's response is > formally correct, but if requests is so important, it's likely to > already be on the approved list. I would assume that pyoic also > implements the client side, so it is useful even if requests is > absent.
In that context, the problem is the old "batteries that leak acid everywhere can be worse than no batteries at all" one: we know from painful experience with the SSL module that the standard library's typical release and adoption cycle can be seriously problematic when it comes to network security related modules. However, when it comes to draconian security policies, *transitive recommendations have power*: if CPython is approved, and python-dev collectively says "we recommend pip, virtualenv, and requests", then folks in locked down environments can use that as evidence to suggest that those other modules are also trustworthy (particularly when there are commercial software vendors shipping them). In the case of something like OIDC, if the requests, Flask, Django and Pyramid developers were all inclined to recommend the same library for server and client implementations, then that would similarly be sufficient justification in many environments to bring the component in as a new dependency. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia _______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
