-
Notifications
You must be signed in to change notification settings - Fork 249
Proposed Code Layout
I propose to turn what right now is the content of our current hamster repository into four distinct packages. Those packages actually just reflect different functional units already present.
In order to ease packaging, development and issue-tracking I strongly favour putting each into its own repository. However, the one-off price for that would be that we reset our git-history and loose existing starts/forks/issues. Then again 2 out of those 4 components are currently rewritten anyway, so it just may be right. And if we feel strongly about not giving up our one central repository we can at least keep just the CLI and GTK - client code in here.
A library that provides a consistent API as well as a plugable backend infrastructure to utilize a variety of means to store our genereated data.
We want to keep dependencies as minimal as possible. The idea here is that any code that want to use our time-tracking functionality (if one buys into our semantical choices) can just inlude this with as little overhead as possible.
This should be packageable within the regular python workflow, straight to pypi and ready to go. local development can happen all nicly within a virtualenv or venv.
A dbus service/client-package builds on top of hamsterlib to provide a dbus service to interact with.
Whilst we may still be able to package this rather straight forwardly, using a virtualenv is somewhat of an issue due to dbus/gtk/gi-dependencies. We will have to see about that.
This one should be a straight forward no brainer.
In order to ease development as well as packaging/deployment this one should realy get its own place. People actualy familiar with the code need to decide if waf is actually needed to build/package this or if we can get along with our regular tools just fine. One way or the other, there should be no reason why this rather hefty part of our project should obscure work/deployment on our backend related packages.