Created by John Leach on 2014-05-06 and last modified on 2014-05-06
Get this branch:
bzr branch lp:~johnleach/duplicity/1315437-swift-container-create
Only John Leach can upload to this branch. If you are John Leach please log in for upload directions.

Branch merges

Related bugs

Related blueprints

Branch information

John Leach

Recent revisions

983. By John Leach on 2014-05-06

  Check to see if the swift container exists before trying to create it,
  in case we don't have permissions to create containers. Fixes #1315437

982. By Kenneth Loafman on 2014-04-30

* Merged in lp:~mterry/duplicity/encode-exceptions
  - Because exceptions often contain file paths, they have the same problem
    with Python 2.x's implicit decoding using the 'ascii' encoding that we've
    experienced before. So I added a new util.uexc() method that uses the
    util.ufn() method to convert an exception to a unicode string and used it
    around the place.
  - Bugs fixed: 1289288, 1311176, 1313966

981. By Kenneth Loafman on 2014-04-29

* Merged in lp:~mterry/duplicity/backend-unification
  - Reorganize and simplify backend code. Specifically:
    - Formalize the expected API between backends and duplicity. See the new
      file duplicity/backends/README for the instructions I've given authors.
    - Add some tests for our backend wrapper class as well as some tests for
      individual backends. For several backends that have some commands do all
      the heavy lifting (hsi, tahoe, ftp), I've added fake little mock commands
      so that we can test them locally. This doesn't truly test our integration
      with those commands, but at least lets us test the backend glue code.
    - Removed a lot of duplicate and unused code which backends were using (or
      not using). This branch drops 700 lines of code (~20%)
      in duplicity/backends!
    - Simplified expectations of backends. Our wrapper code now does all the
      retrying, and all the exception handling. Backends can 'fire and forget'
      trusting our wrappers to give the user a reasonable error message.
      Obviously, backends can also add more details and make nicer error
      messages. But they don't *have* to.
    - Separate out the backend classes from our wrapper class. Now there is no
      possibility of namespace collision. All our API methods use one
      underscore. Anything else (zero or two underscores) are for the backend
      class's use.
    - Added the concept of a 'backend prefix' which is used by par2 and gio
      backends to provide generic support for "schema+" in urls -- like par2+
      or gio+. I've since marked the '--gio' flag as deprecated, in favor of
      'gio+'. Now you can even nest such backends like
    - The switch to control which cloudfiles backend had a typo. I fixed this,
      but I'm not sure I should have? If we haven't had complaints, maybe we
      can just drop the old backend.
    - I manually tested all the backends we have (except hsi and tahoe -- but
      those are simple wrappers around commands and I did test those via mocks
      per above). I also added a bunch more manual backend tests to
      ./testing/manual/backendtest.py, which can now be run like the above to
      test all the files you have configured in config.py or you can pass it a
      URL which it will use for testing (useful for backend authors).

980. By Kenneth Loafman on 2014-04-26

* Merged in lp:~mterry/duplicity/py3-map-filter
  - In py3, map and filter return iterable objects, not lists. So in each case
    we use them, I've either imported the future version or switched to a list
    comprehension if we really wanted a list.

979. By Kenneth Loafman on 2014-04-25

* Fixed bug #1312328 WebDAV backend can't understand 200 OK response to DELETE
  - Allow both 200 and 204 as valid response to delete

978. By Kenneth Loafman on 2014-04-20

# Merged in lp:~mterry/duplicity/more-test-reorg
  - Here's another test reorganization / modernization branch. It does the
    following things:
    - Drop duplicity/misc.py. It is confusing to have both misc.py and util.py,
      and most of the code in misc.py was no longer used. I moved the one
      function that was still used into util.py.
    - Consolidated the various ways to run tests into just one. I made tox runs
      go through ./setup.py test, rather than nosetests. And I made the
      ./testing/run-tests scripts just call tox. Now we no longer need nosetests
      as a test dependency (although you can still use it if you want).
    - Added two more code quality automated tests: a pep8 one and a pylint one.
      I disabled almost all checks in each program that gave a warning. These
      tests just establish a baseline for future improvement.
    - Moved the test helper code into TestCase subclasses that all tests can
      use. And used more code sharing and setUp/tearDown cleverness to remove
      duplicated code.
    - Reorganized the tests in ./testing/tests into ./testing/functional and
      ./testing/unit -- for whether they drive duplicity as a subprocess or
      whether they import and test code directly. Each dir can have specialized
      TestCase subclasses now.
    - Renamed the files in ./testing/unit to more clearly indicate which file
      in ./duplicity they are unit testing.
    - Added some helper methods for tests to set environment and globals.*
      parameters more safely (i.e. without affecting other tests) by
      automatically cleaning up any such changes during test tearDown.
    - Removed test_unicode.py, since it is kind of dumb. It used to be more
      useful, but now with py2.6, we are just testing that one line of code
      in it is actually there.

977. By Kenneth Loafman on 2014-04-19

* Merged in lp:~mterry/duplicity/encode-for-print
  - Encode translated strings before passing them to 'print'.
  - The print command can only apparently handle bytes. So when we pass it
    unicode, it freaks out. There were only four instances I saw where we used
    print, so I figured it was easiest to just convert them to use the log
    framework too.
  - That way all user-visible strings go through that framework and are subject
    to the same encoding rules.

976. By Kenneth Loafman on 2014-04-19

* Merged in lp:~mterry/duplicity/drop-static
  - Drop static.py.
  - This is some of the oldest code in duplicity! A bzr blame says it is
    unmodified (except for whitespace / comment changes) since revision 1.
  - But it's not needed anymore. Not really even since we updated to python2.4,
    which introduced the @staticmethod decorator. So this branch drops it and
    its test file.

975. By Kenneth Loafman on 2014-04-19

* Merged in lp:~mterry/duplicity/2.6isms
  - Here's a whole stack of minor syntax modernizations that will become
    necessary in python3. They all work in python2.6.
  - I've added a new test to keep us honest and prevent backsliding on these
    modernizations. It runs 2to3 and will fail the test if 2to3 finds anything
    that needs fixing (with a specific set of exceptions carved out).
  - This branch has most of the easy 2to3 fixes, the ones with obvious and
    safe syntax changes.
  - We could just let 2to3 do them for us, but ideally we use 2to3 as little
    as possible, since it doesn't always know how to solve a given problem.
    I will propose a branch later that actually does use 2to3 to generate
    python3 versions of duplicity if they are requested. But this is a first
    step to clean up the code base.

974. By Kenneth Loafman on 2014-04-17

* Merged in lp:~mterry/duplicity/drop-pexpect
  - Drop our local copy of pexpect in favor of a system version.
  - It's only used by the pexpect ssh backend (and if you're opting into that,
    you probably can expect that you will need pexpect) and the tests.
  - I've done a quick smoketest (backed up and restored using
    --ssh-backend=pexpect) and it seemed to work fine with a modern version
    of pexpect.

Branch metadata

Branch format:
Branch format 7
Repository format:
Bazaar repository format 2a (needs bzr 1.16 or later)
Stacked on:
This branch contains Public information 
Everyone can see this information.