Duplicity

Backend imports should be made optional

Bug #394757 reported by Kenneth Loafman
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Duplicity
Fix Released
Medium
Unassigned
Duplicity 0.6.03

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.

Revision history for this message
Kenneth Loafman (kenneth-loafman) wrote :

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...

Revision history for this message
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.

Revision history for this message
Kenneth Loafman (kenneth-loafman) wrote : Re: [Bug 394757] Re: Backend imports should be made optional

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?

Kenneth Loafman (kenneth-loafman)
Changed in duplicity:
milestone: 0.6.02 → none
status: Confirmed → In Progress
Revision history for this message
Kenneth Loafman (kenneth-loafman) wrote :

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

Kenneth Loafman (kenneth-loafman)
Changed in duplicity:
importance: Low → Medium
milestone: none → 0.6.03
Kenneth Loafman (kenneth-loafman)
Changed in duplicity:
status: In Progress → Fix Committed
Kenneth Loafman (kenneth-loafman)
Changed in duplicity:
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.
Subscribing...

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.