First, I believe rauth existed prior to your library: rauth is over a year old now. (Or maybe existed at around the same time; regardless as you'll see below, contributing to your project wouldn't have made sense for us.)
Second, you're trying to solve a different problem than rauth solves: we needed a library that provided for the practical, de facto implementation of OAuth 1.0/a and 2.0 as well as Ofly which allowed us to consume provider APIs. This is exactly what rauth does. It loosely wraps Requests, which means you get to basically use Requests that also happens to handle real-world OAuth providers as a consumer. I don't think it's really fair to call this "silly": it's clearly filled a hole in the ecosystem for some people.
If you want to consume an OAuth provider, rauth tries to give you a simple interface to do so with. It's almost as easy as using Requests. You might even say, it's OAuth for Humans. (Sorry, Kenneth. :)
Edit: to be clear, rauth is about pragmatic simplicity, about a clean API that's pleasant to work with. It's a client for OAuth modeled around the fact and philosophy of Requests. Vis-à-vis everything else I've seen, this is in pretty stark contrast to existing libraries.
All the same: OAuthLib and its libraries cover the exact use-case you've laid out, just in a fashion that has some architectural benefits on top of the usability goals. The simple "OAuth for Humans" thing you're reaching for exists—it's https://github.com/requests/requests-oauthlib. Kenneth and I hashed this interface out before we started out on OAuthLib, and thus far it's the only shim library for OAuthLib I know of (though it's pretty simple to write something equivalent which bridges OAuthLib's domain knowledge and any given HTTP request implementation). I even rewrote Requests' underlying auth implementation to make this sort of thing possible. And now you have:
oauth = OAuth1(client_key=key, client_secret=secret)
r = requests.post(url=request_token_url, auth=oauth)
I don't see OAuth1 getting simpler than that, and the underlying signing logic is there for anybody to use in any context—as a provider, consumer, in a stubbing library—whatever!
> All the same: OAuthLib and its libraries cover the exact use-case you've laid out
Nope. They very much do not: your expectation is that your users will roll their own clients or use Requests' shim, which seems a little rough around the edges and doesn't provide for the necessary use cases, e.g. OAuth 2.0 and Ofly. I'm sorry, but this is not providing for the use cases I've laid out by any stretch of the imagination.
Rauth is batteries included, ready to get you up and running in minutes, not hours or days. You won't need to write your own client or patch an existing client to make it work with an unsupported protocol like OAuth 2.0.
> I don't see OAuth1 getting simpler than that
Then you haven't used rauth. The whole auth dance is taken into consideration and various helpers make it a breeze, literally a two or three step process. Further, once you have tokens, it becomes as simple as:
session.get('me')
Now, that's what I call simple.
I think in your attempts to compare your lib to rauth you're missing the broader thrust of rauth: rauth is a client library. It makes using OAuth (1.0/a, 2.0, even the OAuth-ish Ofly) as easy as we can make it. This is far removed from the goal of some generalized, spec-centric, even idealized, implementation of OAuth as a spec. Rauth isn't trying to do that, it's trying to make it easier for you to connect to Facebook or Twitter or whatever provider you happen to need. I wouldn't really know, but I've been told, it seems to shine in this regard. :)
Fair enough. I indeed _haven't_ used rauth, just read the docs. And indeed, OAuthLib's requests shim is a bit rough in terms of tests and docs, but the OAuth1 use-case is quite solid—it doesn't do the dance for you, but every subsequent request is the bulk of the work (in my experience). For that application, the API's seem pretty similar to me—you can instantiate a requests session with a set OAuth auth object and make requests like "session.get(some_uri)" without the magical per-service mapping.
I guess I just feel like tying to one specific service is too specialized. Libraries like requests should be providing you with enough primitives to be flexible and enough abstraction to be "simple," though we clearly disagree on what constitutes the appropriate balance.
Thanks for your work on rauth, I've been using it for a long time and I'm hoping to update my projects to use the latest version to pick up requests 1.x support some time soon.
Second, you're trying to solve a different problem than rauth solves: we needed a library that provided for the practical, de facto implementation of OAuth 1.0/a and 2.0 as well as Ofly which allowed us to consume provider APIs. This is exactly what rauth does. It loosely wraps Requests, which means you get to basically use Requests that also happens to handle real-world OAuth providers as a consumer. I don't think it's really fair to call this "silly": it's clearly filled a hole in the ecosystem for some people.
If you want to consume an OAuth provider, rauth tries to give you a simple interface to do so with. It's almost as easy as using Requests. You might even say, it's OAuth for Humans. (Sorry, Kenneth. :)
Edit: to be clear, rauth is about pragmatic simplicity, about a clean API that's pleasant to work with. It's a client for OAuth modeled around the fact and philosophy of Requests. Vis-à-vis everything else I've seen, this is in pretty stark contrast to existing libraries.