Here's my suggested interface, instead of

@tk.blanket_implementation(tk.Blanket.cli)
class ExampleBlanketCliPlugin(p.SingletonPlugin):
    pass

How about:

@tk.blanket_cli
class ExampleBlanketCliPlugin(p.SingletonPlugin):
    pass

Then we just have blanket_helper, blanket_auth, blanket_action, blanket_blueprint defined the same way. This is explicit, concise, provides a clear pattern for future blankets and allows each blanket to have its own custom parameters

I thought about something similar - after the discussion on Thursday having separate decorators has much more sense for me both in terms of extensibility and unambiguity(and I'm going to remove all option, whatever implementation we'll choose - it will only create more possibilities for incompatible changes every time blanket will change). it won't be difficult to add multiple decorators to class and it shouldn't look too cumbersome as long as decorators are simple.

The only thing I'm concerning about when it comes to registering every blanket as toolkit item - won't there be an overwhelming number of toolkit members if we continue with adding everything there? So, instead of tk.blanket_cli, tk.blanket.cli form looks tidier from my point.

And some thoughts about the future evolution of this decorator. If there will be cases when the interface has few methods and we want to cover all of them, there should be some implementation aligned to single-method interfaces. For example, in the case of IFacet, it would be quite straightforward to create facets.py with three methods [dataset_facets, group_facets, organization_facets], or pass as decorator argument function, that'll return required functions. But is there any sense to account such options, or let's from the very beginning pin blankets to only simplest single-method interfaces and other interfaces will be considered as requiring classical implementation?

Personally, even though it sounds like "cool, they allow us to write less code", I'm leaning to restricted use-cases of blankets - initial idea was to provide a simple mechanism of reducing plain boilerplate. If this mechanism will be hard to get, will have some complex use-cases - we'll just end up with having two equal ways of doing the same thing, what I don't like at all.

Updated as per @wardi 's suggestion. I've added documentation, and if anyone is too lazy to build it locally, here's how it looks:

@amercader any comments on this?

@smotornyuk sorry I let this sit, can you fix up the conflict so we can merge. I like this feature

No problem, I won't be able to use this feature in production till the official release anyway:)

Thanks @smotornyuk for the changes!

Sorry @smotornyuk , not sure why but when merging this PEP8 tests failed in master. Can you have a look?

Sure