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

Open
willkg opened this Issue Aug 6, 2013 · 4 comments

2 participants

@willkg
Mozilla member

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
Mozilla member

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

@willkg
Mozilla member

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
Mozilla member

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
Mozilla member

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment