Moving to 1.13 development
Updating RELEASING with PyPI info
Start using flake8 during dev
Major refactor of swiftly.cli

Changes to swiftly.cli:

This is a major refactoring of swiftly.cli. The module was getting
pretty hard to manage so I split it up into various pieces inside a
package. Because things changed so much here, I think it's time to
bump to version 2.0 on the next release.

I can't list all the changes to swiftly.cli here without including
almost all the code; so just go look at the code.

Changes to swiftly.client:

Even though swiftly.client has also been promoted to a package, the
external use of it really hasn't changed. It just seemed like a good
place to put the brand new ClientManager and I didn't want to add yet
more to what was a single file. I will probably split
swiftly/client/__init__.py out a bit more later.

There was a bug fix to case-mismatched output headers; previously it
could send out User-Agent and user-agent for example.

Verbose output got a bit more verbose by including the headers sent.

More Exceptions are now caught; courtesy of IAD closing my
connections mid-stream so often.

Also, get_account and get_container have a new decode_json option.
This defaults to True to retain the previous behavior but, if set to
False, the resulting contents will be the raw response body instead
of the decoded JSON.

And there's the new ClientManager and IOManager classes. The
ClientManager is created just like Client, but then you ask the
manager for clients to use and put them back when your done. The
IOManager is just an oddity that makes swiftly.cli a bit easier to
implement.

Changes to swiftly.concurrency:

This has always been a bit of work-in-progress. It has changed to
capture any Exceptions and Timeouts and return that information as
well as actual results. Anybody using this (which is probably nobody
but Swiftly itself) will have to update accordingly.

Changes to bin/swiftly:

The command line tool itself, swiftly, really hasn't changed much in
its usage. There is the exception that -I has gone away for deletes,
posts, and puts. Instead, -i now supports a single dash as
representing stdin and representing you want a body even when one is
not normally used. So what was "somecommand | swiftly delete -I" is
now "somecommand | swiftly delete -i -" and what was "swiftly delete
-Ii somefile" is now "swiftly delete -i somefile".

There's a new environment variable option, SWIFTLY_CONCURRENCY, so
you don't have to specify --concurrency all the time.

The auth command got a bit more information.

The get command got a new --remove-empty-files option that is pretty
useful in conjunction with --sub-command. It just removes any files
it stores on disk that end up empty (presumably after having gone
through a sub-command filter).
Major refactor of swiftly.client

Now it was swiftly.client's turn for renovations.

I split the Client class into a base class with two subclasses,
StandardClient and DirectClient. Should be easier to manage now
though it does mean any users of the Swiftly code library are almost
certainly going to have to update at the 2.00 release.

The clients themselves have changed only a little in their usage.
Existing users of the library should just have to alter how they
construct the client, but usage past that should remain the same.

The general utility functions that were in swiftly.client I moved
into swiftly.client.utils, though generate_temp_url and
get_trans_id_time are still importable from swiftly.client for
convenience.

I also split out LocalMemcache and NullLogger into their own files.

The ClientManager got altered a bit to reflect the change in the
Client construction.

I also moved IOManager to swiftly.cli.iomanager since it had little
to do with swiftly.client really.

The auth caching now uses a more secure method and should no longer
be prone to race conditions.

I think that's it. All the documentation should be up to date. Oh,
and I removed what tests there were because those haven't been being
maintained for quite some time. Another item for the TODO list.

Fixed #31
Minor doc bug
Fix small bug with request and strings

Now converts string-based content into StringIO instances so they can
have .seek and .tell and therefore allow the code to work that does
resettable uploading on error.
Merge branch 'master' of github.com:gholt/swiftly
Fixed bugs w "swiftly put" static segments
Fixed bug with directclient verbose
Fixed return exc_value to raise
Updated README.md and RELEASING

I guess I never read about git and tags and realized I really wanted
branches.
Added new (de|en)cryption options

The put command now supports --encrypt=KEY and the get command now
supports --decrypt=KEY to use AES 256 in CBC mode via PyCrypt
https://www.dlitz.net/software/pycrypto/ (perhaps more options
later).

Also provided reusability of such through swiftly.dencrypt and
swiftly.filelikeiter -- the latter based on some quick work I'd done
before for OpenStack Swift.
Disabling put encrypt segmented objects and more

Segmented object support needs multiple opens and seeks and isn't
compatible with encryption support.

Made encryption support a set content-length in case it's needed.

Made segmented object support HEADing the segment in case it doesn't
already have the required resulting content-length and etag (really
should never happen, but just in case).

Also fixed a bug with standardclient's put_object call with a set
content-length that can't complete reading.
New encrypt and decrypt cli commands

Useful for local encrypting and decrypting.
More title links in docs
Changed Contents to API Reference
Disabled using --different and --encrypt together
Made -H a synonym for -h and -h show help on error

The previous -hheader:value still works fine, I just added
-Hheader:value since so many folks used to curl do that. And folks
are also typing things like "swiftly get -h" to try to get help and
instead were just getting an annoying "-h option requires an
argument", so I made that case also output the command help.
Make pycrypto optional