The "contrib" doesn't seem to provide anything helpful at all and just makes all the module names longer.
Figure it's worth doing now that @jezdez wants to make the Django stuff moar awesome.
Hm, what if we'd add a flask extension later? Basically just add it to elasticutils.flask or something?
Yeah, we could put it in elasticutils.flask.
Alternatively, it's possible that at that point it might make more sense to put that in a separate project called something like elasticutils-flask. I have the Django stuff in elasticutils right now mostly for convenience of packaging. I'm not sure I want elasticutils to grow to include code for Flask, Django and all the web frameworks if only because it'd be a pain in the ass to test and maintain it all.
This is off the top of my head. I haven't been planning to write convenience stuff for other web frameworks and no one has been interested as far as I know.
Understood and totally agreed. As soon as anyone wants to support another framework I think it makes sense to have another package. But I could see a django-elasticutils having the Django specific helpers while elasticutils would "only" be focused on the core features. But again, this is probably more maintenance effort than it's worth as long as there is only one framework involved.
Figured it was worth mentioning this for context purposes. Originally elasticutils was extracted from AMO and was django-only. When I took over, I generalized the core to be universal and put the django-specific bits in contrib. I thought about putting that in a separate project, but didn't because it would have been (slightly) harder for Mozilla projects using elasticutils to update and (slightly) harder to maintain two packages instead of one.