> On 17 Nov 2016, at 12:58, Cory Benfield <c...@lukasa.co.uk> wrote: > > >> On 16 Nov 2016, at 14:53, Paul Moore <p.f.mo...@gmail.com> wrote: >> >> I'm not a web developer as such, although I do write code that >> consumes web services on occasion. I don't know what OIDC is, but I do >> know, for example, that some services use OAuth. So I can imagine >> being in a situation of saying "I want to get data from a web API xxx, >> and it needs OAuth identification, how do I do that in Python?" >> Typically, the API docs are in terms of something like Javascript, >> with a browser UI, so don't help much for a command line script which >> is the sort of thing I'd be writing. In that situation, a well-known, >> easy to use module for OAuth in Python would be fantastic. >> >> Agreed that it could as easily be on PyPI as in the stdlib, but >> discoverability isn't as good with PyPI - I can scan the stdlib docs, >> but for PyPI I'd end up scanning Google, and what I found that way was >> oauthlib - I didn't see any mention of pyoidc. I can't comment on what >> that implies, though. In my brief search though I didn't find any sort >> of command line "Hello world" level example. > > I think this is actually another great example of why we should resist > attempts to add modules to the standard library without enormous caution. I > think that fundamentally in most of these cases the audience on python-dev is > not equipped to decide whether an implementation deserves to become a default > battery. And this is a surprisingly good example case. > > With all due respect to Roland, pyoidc is not the incumbent in the > synchronous OAuth space: requests-oauthlib is. A quick Google search for > “python oauth” turned up the following client libraries in my top 10 results: > oauthlib (discarded because it’s a sans-IO implementation that recommends > requests-oauthlib as a client), python-oauth2, requests-oauthlib, and > Google’s OAuth 2 client library (discarded because it is bundled into the > Google API client libraries module and so distorts my download counts below). > > A quick query of the PyPI download database for the three months shows the > following download counts for those modules: > > - requests-oauthlib == 1,897,048 > - oauth2 == 349,759 > - pyoidc == 10,520 > > This is not intended to be chastening for Roland: all new modules start with > low download counts.
No offence taken ! :-) But you should distinguish between OAuth2 and OIDC. OIDC is a profile of OAuth2 for usage in the case where you not only need authorization (and access tokens) but also authentication and/or user info. > As the current lead maintainer of requests-oauthlib, let me say publicly and > loudly that I’d love to have pyoidc replace requests-oauthlib. I *hate* > requests-oauthlib. I maintain it literally only to prevent it falling into > disrepair because it is extremely widely used. I would love a better library > to come along so that we can sunset requests-oauthlib. I am entirely prepared > to believe that Roland’s module is better than requests-oauthlib: it would be > hard for it not to be. :-) > However, *right now*, pyoidc does not have anything like a majority (or even > a plurality) of mindshare amongst Python developers writing OAuth clients. So > why should pyoidc be added to the standard library over the competing > implementations? The only reason I can see to add it is if it is a better > implementation than its competitors, and the python-dev community believe > that developers using the competitor implementations would be better served > using pyoidc instead. Is that the case? Do we have some objective measure of > this? The only possible objective measurement I can see would be testing the implementation for standard compliance. > Paul, you mentioned that discovery on PyPI is a problem: I don’t contest that > at all. But I don’t think the solution to that problem is to jam modules into > the standard library, and I think even less of that idea when there is no > formal process available for python-dev to consider the implementations > available for the standard library. Instead, I think we need a way to be able > to ask the question: “what does the wider Python development community > consider to be the gold standard for solving problem X?”. I do not think that > adding modules to the standard library is the way to answer that question. > > The TL;DR of this massive argument is: I think the community of people who > actually use OAuth on a regular basis are better placed to judge what the > best-in-class battery for OAuth is. What we need is a way to surface their > collective opinions to people who don’t know what options are available, > rather than to make commitments to long-term support of a module in the > standard library. > >>> 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 should also note that I rely heavily on the stdlib, and for a >> non-trivial amount of the work I do (which is one-off scripts, not >> full-blown applications) having to go outside the stdlib, other than >> for a very few select modules, is a step change in complexity. So I'm >> a fan of the "batteries included" approach. > > I think this is the other problem that needs solving, and because I’m a > full-time OSS developer with complete admin rights on my development and > production targets I’m badly placed to solve it. What needs to be done to > make it easier for people in your position to obtain non-included batteries? > Can anything be done at all? > >> I don't know whether OAuth is a sufficiently common requirement to >> warrant going into the stdlib. My instinct is that if you're >> integrating it into a web app, then there's no value in it being in >> the stdlib as you'll already need 3rd party modules. If it's practical >> to use OAuth from a simple Python script (say, to integrate with a web >> API like github) then being in the stdlib could be a benefit. But how >> many people write Python scripts that use/need OAuth? I've no feel for >> that. > > Yeah, OAuth from Python scripts isn’t entirely uncommon. It’s mostly used to > interact with third-party APIs, which usually use OAuth to allow for > revocable and granular permissions grants to specific scripts. > > Cory > _______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
