The OAuth is complicated. Is it worth to maintain both OAuth and OAuth2 in a single codebase?
Andrei Fokau's profile photoOndrej Slinták's profile photoanatoly techtonik's profile photoIb Lundgren's profile photo
I believe so. Having two separate packages does not reduce the complexity, does it?
Given the fact that OAuth2 is not compatible with OAuth, it reduces complexity of the code, because you don't have to keep in mind those differences while reading the codebase.

OAuth2 implements an RFC, and it is confusing what non-RFC code has to do with implementation?

It is a big problem to find a clear, concise, working, tested and overly good implementation of OAuth2 nowadays (with animations).
The two parts do not depend on each other, so there is no confusion from my point of view. If you do not need oauth1 part (which is clearly trying to follow RFC 5849), you simply do not use it, or do not commit code for it. Adding yet another package to the oauth soup would indeed increase complexity.
The two parts may not depend on each other, but they probably depend on the shared functionality, and shared functionality usually affects the way the code is written.

The RFC 6749 (OAuth 2) obsoletes RFC 5849 (OAuth 1), so the presence of two implementations (and the name draft25) makes me think about other things that are left in code for backwards compatibility.

What you're saying about is probably "maintenance complexity", not "code complexity". It is not even "usage complexity", because from the point of OAuth users they still need to choose either OAuth 1 or OAuth 2. They can't use both at the same time, and even if they do - it's quite unlikely that a single endpoint will be used for that.
+anatoly techtonik OAuth2 doesn't obsolete OAuth1. They share the same name but are quite different in many aspects. Some people even still consider OAuth1 to be superior.

Besides, if you look at oauthlib codebase, it doesn't share any parts between 1 and 2 that would cause troubles. It's usualy just helper methods (for generating tokens etc).

Regarding implementation of OAuth2's RFC, I believe +Ib Lundgren is working on it and it should be ready for testing soon.

In short: If you don't need to use OAuth1, just don't use it, but IMO it's still worth to maintain it.
+Ondrej Slinták you may say that OAuth1 doesn't obsolete OAuth2, but RFC 6749 says otherwise -

I agree that actual code is not tightly coupled, but this fact is only evident after actually asking or reading the code, which users of the library rarely do. If the lib seems too complicated - they bounce.

So, while your facts provide additional info, they doesn't cancel the argument that from the user's perspective it is better to see different in many aspects and independent on each other libraries in different projects.
I've added my thoughts to the github issue.

Regarding OAuth 2 obsoleting OAuth 1 that is not quite true, yet. There are still use cases that are not covered by OAuth 2, the ones being users that are unable to rely on SSL (partially addressed in the abandoned MAC token spec) and Holder of Key assurance (supposedly addressed in the upcoming Holder of Key). 
Add a comment...