Move algorithm-specific logic to be class-based to allow for better extensibility about pyjwt HOT 4 CLOSED

As an alternative, setuptools extension points could be used instead. With the current approach, any external "extension package" containing an additional algorithm implementation must be imported by the application before it could be used, because the extension package would register the algorithms only at import time.

With extension points, which are designed for use cases like these, this isn't needed anymore. A simple pip install pyjwt pyjwt-my-supercool-new-crypto-algo-addon would suffice.

The stevedore package takes care of most of the required plumbing; see http://stevedore.readthedocs.org/en/latest/index.html for details and examples. The "driver" approach would work for the use cases outlined in this issue, I think.

from pyjwt.

That's a neat idea! I could see that being super useful in applications that see a lot of plug-ins being developed (things like Django, SqlAlchemy, flask) and I have some ideas for where I want to use it. Thanks for sharing it! =)

For this library, I anticipate that 99.9999% of the use-cases will be people who are only using the algorithms listed in the JWA spec (which we implement all of the required, all of the reccomended, and most of the optional). I think that someone registering their own non-standard algorithms with this library would be very uncommon so I'm not sure it justifies the additional dependency on stevedore.

I wouldn't be opposed to the setuptools option though. I'll have to read up on it.

But that's just my two cents :-)

from pyjwt.

Actually I tend to agree with you here @mark-adams. The ugly import-time side-effect and the resulting seemingly "unused" import in application code is just the price one has to pay for using non-standardized crypto! :)

from pyjwt.

For future reference: follow-up discussion in #71.

from pyjwt.