Michael Terry wrote: > Hello! I was talking to Rob Oaks from Time Drive a while back about > possibly merging efforts. That sort of broke down because I said I > was too invested in my 'call-duplicity-then-interpret-logs' method and > he was too invested in his 'use-duplicity's-Python-module' method. > But that got me thinking.
Dangerous process, thinking... ;-) > Deja Dup may be ported to Python at some point, and I wanted to ping > you, Ken, on what a stable duplicity Python module would look like. I > don't know how much you consider possible users of the module when > making changes. Rob could tell you much more about which bits of it > he uses. It's not really modular at this point. There are a few classes, but most activity is via straight function calls. An API would be handy, move the contents of duplicity-bin into duplicity module, make classes as needed, and leave a thin shell as the executable. When I'm making changes to duplicity-bin, I do not consider anyone to be a module user. There are too many pathological dependencies there. If we go modular, backwards compatibility would then be a consideration. > It seems like we have 4 main UIs, duplicity (CLI), duply (CLI), > deja-dup (GNOME), and time-drive (KDE) [1]. This touches on all of > them, so I pulled in Edgar in the To: list. Hmmm, wonder who else is not on the mailing list, all should be. I notice that he has joined now. > There are two main ways of currently dealing with duplicity's core: > Python module (used by duplicity and time-drive) and CLI/logging (used > by duply and deja-dup). I'll note though, that duply doesn't actually > use the logging side of things. I'm the only log consumer. Still would be handy if we go the syslog route, centralized logging. > (A) Are we consuming resources maintaining two? I think at this > point, the logging is pretty stable and doesn't require much effort > (correct me if I'm wrong Ken). But it is strictly add-on work on top > of the module, which you have to maintain regardless. Logging is very stable at the moment, I don't see any change needed. > (B) Do we need two? I'm willing to drop the logging in favor of a > pure module approach, with the goal of porting Deja Dup to Python at > some point. But keeping it for now makes my life easier, since I > already have all the code written. Edgar, I don't know if you had > plans to use logging. If we want to encourage non-Python wrappers, we > would need to keep it. Logging should be integral with the pure module approach, possibly even opened up as a resource in the API. We may not actually use it for user output, but for debugging, its vital. > (C) Is a module a reasonable approach? Ken, how stable is the > module's classes/methods/API? Should we start thinking about more > formally defining an API? Yes, a formal API would be good, as I said above. I'm already doing Epydoc on a regular basis and would like to continue. We can use that to help formalize an API. > [1] This reminds me, as we are getting more frontends, it might be > nice to have a more official section on the duplicity website for > frontends. Maybe a section in the left nav bar, with a quick > description of each and what the target audiences are. Yes. I still need to add Time Drive, but it's to the point now where the front page is too busy, so a separate page would be handy. ...Ken _______________________________________________ Mailing list: https://launchpad.net/~duplicity-team Post to : [email protected] Unsubscribe : https://launchpad.net/~duplicity-team More help : https://help.launchpad.net/ListHelp
