duplicity-team team mailing list archive

[Kenneth Loafman <kenneth@xxxxxxxxxxx>]

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