This branch adds a simple clone wrapper, along with a manage.py command and some tests for it. The tests unpack a local testing repo that can be cloned so testing doesn't depend on a network connection and is still fast.
I put everything in api/data.py for now, but we might eventually think about breaking it out into its own api/repo.py module or something. Probably not until we start doing writes though.
The local testing repo can eventually contain sample course data for testing other aspects of data. It's kept in a tarball because otherwise git wants to treat it like a submodule and things get screwed up. TestData handles unpacking it and cleaning up after. It's cloned to a temporary directory.
This builds on the config branch I opened, since dealing with remotes should be configurable. As long as whatever we implement for configuration is importable from api as config and acts like a dict, there should be no problem.
This branch adds a simple clone wrapper, along with a
manage.py
command and some tests for it. The tests unpack a local testing repo that can be cloned so testing doesn't depend on a network connection and is still fast.I put everything in
api/data.py
for now, but we might eventually think about breaking it out into its ownapi/repo.py
module or something. Probably not until we start doing writes though.The local testing repo can eventually contain sample course data for testing other aspects of data. It's kept in a tarball because otherwise git wants to treat it like a submodule and things get screwed up.
TestData
handles unpacking it and cleaning up after. It's cloned to a temporary directory.This builds on the config branch I opened, since dealing with remotes should be configurable. As long as whatever we implement for configuration is importable from
api
asconfig
and acts like adict
, there should be no problem.