jesteria
commented
11 years ago Separate repos
There's a good chance that this will make sense / be useful eventually. For the time being, I think we gain a tiny bit (maybe trivial) from having everything together, (while the model thrashes); and later, even if we never separate them out, I don't see it being much of a difficulty. Anyway, let's definitely keep this in mind and discuss.
Splitting out the history app / API from the user (HTML) front-end
We discussed this a bit, and didn't come to any conclusions as to whether it would serve any need. There's a bit of user overhead from every packaging split, and I'm not sure that a user who didn't want the front-end would gain much from the API-only distribution. But we should definitely come back to this, as well.
As for separate API and front-end setup.pys, this only goes to whether they're distributed together or not, I think; their setup (requirements) are identical, no?
Was going over the code a bit more last night and was wondering a few things:
Does it make sense to pull the client out into its own repo? Does the "history" application really need to live alongside the server? Seems like that's really an independent application to some degree. Either way, deploying the project itself, such as changes to the wsgi file, shouldn't require deploying changes to the history application either.
Was looking into getting a public instance stood up, and some deployment scripts written, but wanted to address some of these concerns first.
If we do separate the client/server, was simply thinking: omnispective-server omnispective-client
history would still live in the server repo, but would have its own setup.py I was thinking. That should give us most of the flexibility we need probably.