[Duplicity-talk] Developers: backend source re-organization

[Peter Schuller]

Hello,

So I would like to re-organize the way backens are structured in the source.

Motivation:

(1) It just generally makes sense to not have them all in one giant module.

(2) Several times in submitting some patches I have felt that I've had
    to "swallow my pride" and do ugly stuff as a result of it; e.g. creating
    an instance method, or no method/function at all, just because I don't
    want to clutter upp the surrounding backends module with junk related to
    a specific backend.

(3) For further work on concurrent upload support (the beginnings of which
    are in [1]) several changes relating to the backend interface would have
    to be made (details are in previous posts to this ML a few months back),
    so it would be nice to get such a re-organization done with.

I think Kenneth has indicated he want's to do something about the
backends too.

Before I do, since it's basically a bunch of boring mechanical work so
I might as well request objections first, here is an approximate plan:

Move the generic Backend interface into a "duplicity.backend"
module. Create a "duplicity.backends" module[2] whose sole purpose is to
contain individual modules for individual backends.

I specifically want to move things away from the "duplicity.backends"
module because I want individual modules to be able to import and use
the generic module containing the generic interface and some module
registration logic - but a submodule cannot import it's parent (except
by hacks involving deferred non-top-level imports) due to the module
loading mechanism in Python. So that stuff goes into
"duplicity.backend" instead.

Each backend would move into its own dedicated module which, upon load
time, would register it as an available module. If the module
determines that it cannot operate due to a missing dependancy, it
registers a dummy module which, when actually used, will explain that
this is the case.

As part of the initial changes, or after them, the various individual
modules would be given a slight polish to no longer do things like
randomly importing modules at some arbitrary location, trying instead
to do conditional importation/functionality checking in a more formal
explicity phase (this, aside from IMO being nice, also goes towards
making it easyer to make backends properly thread-safe).

So:

(1) Does anyone have objections to anything said above?

(2) Does anyone feel I should specify more detail before attempting anything, 
even
    if you may agree with what has been said?

(3) Is anyone aware of existing patches, or do people have their own patches
    not yet public, that would massively conflict with the above? The problem
    is that in terms of CVS version management it's going to cause problems
    for any concurrent development.

Due to the concurrency problem mentioned in (3), I'd like to
co-ordinate with Kenneth once it's agree that it seems like a good
idea, such that once greenlight is given I can work up the patches and
get the committed fairly soon thereafer, to minimize problems for
other people doing any work on the code base.

[1] https://savannah.nongnu.org/patch/?6353
[2] Making it a "package", but I never understood the motivation behind
    that distinction, and prefer to think of it as an hierarchy of modules.

-- 
/ Peter Schuller

PGP userID: 0xE9758B7D or 'Peter Schuller <address@hidden>'
Key retrieval: Send an E-Mail to address@hidden
E-Mail: address@hidden Web: http://www.scode.org

pgp2ujJ1Pj6sZ.pgp
Description: PGP signature