search

mozilla / elasticutils

[deprecated] A friendly chainable ElasticSearch interface for python
http://elasticutils.rtfd.org
BSD 3-Clause "New" or "Revised" License
243 stars 76 forks source link

nix "contrib" in elasticutils.contrib.django #163

Open willkg opened 11 years ago

willkg commented 11 years ago

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.

We should:

  1. move the django code up a directory
  2. provide backwards-compatible-happy-stuff so doing "from elasticutils.contrib.django import S, F, YourSink" continues to work
  3. write some tests to make sure the old imports work
  4. update the docs and make it clear that the old paths are deprecated and will go away at some point p
jezdez commented 11 years ago

Hm, what if we'd add a flask extension later? Basically just add it to elasticutils.flask or something?

willkg commented 11 years ago

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.

jezdez commented 11 years ago

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.

willkg commented 11 years ago

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.