Backend imports should be made optional

Bug #394757 reported by Kenneth Loafman on 2009-07-02
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Duplicity
Medium
Unassigned

Bug Description

Certain backends require other modules, ncftp for FTP, sftp for SSH, etc.. If the user is not going to be using these modules, it should not be a requirement to have them on the system. I propose that we surround all backend imports with a try/except and that all modules should check requirements at import time prior to calling register_backend. If a backend fails to load, the default should be silence, however a verbosity of INFO or better should show why.

There should also be a 'duplicity list-backends' that will show available backends and their protocol strings, something like:
ftpbackend ftp://
sshbackend ssh:// scp://
...and so on...

Peter Schuller (scode) wrote :

I have some reservations about silently ignore import failures of entire backends. I think I would prefer the backends themselves to do any 'tricks' they might want to do with respect to not importing modules that we consider to be optional.

The intent is to avoid making it easier to introduce problems that don't show up during development because code was not even imported.

But I definitely like the concept of listing backends and whether or not they "think" they are available, along with how to use them.

Peter Schuller wrote:
> I have some reservations about silently ignore import failures of entire
> backends. I think I would prefer the backends themselves to do any
> 'tricks' they might want to do with respect to not importing modules
> that we consider to be optional.
>
> The intent is to avoid making it easier to introduce problems that don't
> show up during development because code was not even imported.
>
> But I definitely like the concept of listing backends and whether or not
> they "think" they are available, along with how to use them.

I agree with the 'silent' part. If a backend fails to load, it should
be noted, but I don't think a traceback is appropriate, maybe just more
detail somehow.

As to listing backends, maybe 3 columns, Name, Proto, Avail, and
possibly a 4th to list what's missing (executable, python module).

On the detail part, we could add 2 routines to the backend.py file,

1) try_import - try to import the foreign module, anything not in the
base Python distribution and notify if that fails.

2) try_exec - try to execute a utility, like ncftp, and notify if that
fails.

The backend could then execute these prior to registering. If one or
both fail, register as 'not-available'.

Thoughts?

Changed in duplicity:
milestone: 0.6.02 → none
status: Confirmed → In Progress

I have just pushed a new branch for 'optional-backends'. It's still a work in progress, but the essential idea works correctly.

Changed in duplicity:
importance: Low → Medium
milestone: none → 0.6.03
Changed in duplicity:
status: In Progress → Fix Committed
Changed in duplicity:
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers