I would ask for a little more separation of concerns. One package for raw but cleaned data with a collection of schemas, and a second for loading arbitrary data + schemas in to Django (and probably accomplishing all of the extra administrative steps provided in the example).
That way if I want to add other schemas for a non-Django use in the same package (say if I care more about analysis than clicky-interfaces) or not use Django, I can still use a package manager for the same data.
Comments
Love the idea!
I would ask for a little more separation of concerns. One package for raw but cleaned data with a collection of schemas, and a second for loading arbitrary data + schemas in to Django (and probably accomplishing all of the extra administrative steps provided in the example).
That way if I want to add other schemas for a non-Django use in the same package (say if I care more about analysis than clicky-interfaces) or not use Django, I can still use a package manager for the same data.
I agree that something more generic and less-Django specific has a lot of appeal, I'm just not sure I know exactly how to pull it off.
Our experiment in the post is based on our previous packaging experience, which is largely limited to pip and setup.py.
You haven't lived until you've been confronted with a python package failure.