[Pulp-dev] 3.0 API module organization question

[Sean Myers]

We've got a bunch of models, so we (wisely, I think) break them up
into submodules in the platform app's models namespace so that they're
easy to find.

In my work on the 3.0 REST API, I'm mirroring this layout when defining
the serializers, because we're pretty likely to have at least one
serializer for every model, and we're also pretty likely to have
a few custom fields on those serializers, as well.

This is working well, but seems to me to be a bit of a rabbit hole when
other API components are taken into effect, particularly ViewSets. Each
API endpoint is represented by a ViewSet, and each ViewSet is related to
a Django Model and that Model's Serializer. While we won't necessarily
have a ViewSet for every Model, we're pretty likely to have a whole lot
of them, so it seems like they should be similarly organized.

So, my question is: Should we generally break up Model-related objects the
same way we've broken up our models (like ViewSets, Serializers, etc)?

Pros:

All objects (Models, Serializers, ViewSets, etc) are in a single
module's namespace. This makes them easy to discover when initializing
apps, and also raises errors related to circular import issues very
quickly. Discoverability, in particular, is Pretty Important™.

Cons:

  /me writes pulp.app.models.foo.Foo
  /me imports Foo into pulp.app.models
  /me writes pulp.app.serializers.foo.FooSerializer
  /me imports FooSerializer into pulp.app.serializers
  /me writes pulp.app.viewsets.foo.FooViewSet
  /me imports FooViewSet into pulp.app.viewsets
  /me is le tired, but gets over it because at least things are consistent?

I think it makes sense to keep things broken up just like the models, but
I'm nervous about how deep this rabbit hole might be, and if at some point
it just becomes a ridiculous maintenance headache. :)

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 851 bytes
Desc: OpenPGP digital signature
URL: <http://listman.redhat.com/archives/pulp-dev/attachments/20160914/6a51702a/attachment.sig>