[Python-ideas] Support for OAuth2/OIDC in the standard distribution ?

[Cory Benfield]

> On 16 Nov 2016, at 13:30, Roland Hedberg <roland at catalogix.se> wrote:
> 
> 
>> On 16 Nov 2016, at 14:50, Cory Benfield <cory at lukasa.co.uk> wrote:
>> 
>> I think the core question you need to answer for this proposal is: why is “pip install oic” not easy-enough reach?
> 
> Basically, I think it’s a matter of visibility.
> If someone tells you you have to add OIDC RP capabilities to your service what do you do.
> If the needed batteries are already included in Python it’s easy, it’s there.

Ultimately I think that this is a bit misleading. Python’s included batteries are often not the best way to add certain bits of function to your program, and Python programmers are extremely accustomed to needing to get their batteries from elsewhere. Certainly web developers are: web developers cannot even really get started without pip installing *something* unless they plan to hand-roll WSGI using wsgiref or use SimpleHTTPServer, which they overwhelmingly do not.

> The OIDF will publish information about their preferred set of libraries but I still think
> there will be a substantial portion of coders we won’t reach.
> 
> If you have any idea about how we could reach more coders I’m all ears.

Coders who need OIDC will go looking for it and will find their options. Ultimately, a huge number of projects haven’t suffered from being outside the standard library. Some of these are even replacements for Python’s included batteries, which means they’re competing with the “just there” options users already have.

It should be noted that I believe that Python’s standard library is already too big, and has had a tendency in the past to expand into cases that were not warranted. I think that saying that you’re worried that users won’t find your module and so it should go into the standard library is solving the wrong problem. We shouldn’t just shove useful things into the standard library because they’re useful: that leads to a massive, bloated standard library that is an enormous maintenance burden for the Python core developers who frankly have more than enough to be doing already. Instead, we should aim to solve the actual problem: how do we provide tools to allow users to find the best-in-class solutions to their problems from the third-party Python ecosystem?

That there is a much harder problem, unfortunately, but I think we should aim to provide a bit of impetus towards solving it by refusing to add things to the standard library that aren’t likely to be extremely broadly useful.

Cory