Initial commit.
Add .gitignore
Introducing Taggart: The simple file tagger.
Add support for a slightly different paradigm...

Some applications might work better if tags have
files, as previously. Others will probably work
better if files have tags, as now. The setting is
interchangeable, and the default has been left at
the old way (tags have files) due in particular
to one interesting observation: The most
resource-intensive operation in either case will
be renaming. If "tags have files", renaming a
file is a pain. If "files have tags", renaming a
tag becomes a pain (just look at OS X: have you
ever tried to change the colored dot of a tag
that happens to be applied to many, many files?
See how long it takes? That's because "files have
tags"... and every one of those tags, plural,
now needs to be updated because you changed one.)

In considering the initial design, I made the
assumption that tags will be applied/removed on
a file-by-file basis more often than on a
large-scale basis, so "tags having files" was a
design paradigm that fit well, even if it sounds
a bit counter-intuitive. I also made the
assumption that a global rename of a tag is
probably more likely than a rename of a file to
which many tags apply.  It might take slightly
more memory this way, if only because filenames
tend to be longer than tag names, and if one file
happens to be owned by many many tags... well...

"That's crazy! Users rename files all the time!"

True enough. The observant reader will notice
I just renamed a file in this very commit. This
very valid concern is precisely why I decided to
add support for the "files have tags" design
paradigm as well. So, it's there if you need it.

For myself, however, and the specific application
that this project may or may not benefit (we'll
see) file renames are not only infrequent, they
are blatantly discouraged: Even renaming a file
in Git is not without traceability consequences.
So, the "tags have files" paradigm still makes
more sense, at least for the time being.

Time will be the real telling factor on that one.

But hey, now you're not locked into a bad design!

Choose wisely.
On second thought, let's have a standard output.

Related to the design paradigm discussion in the
previous commit, I think it's probably a good
time to highlight why I chose NOT to use JSON or
YAML as the output format: For one thing, the
hurdles and limitations that must be overcome in
memory by making either tags OR files the primary
reference point would not be alleviated by using
a data storage format that is inherently plagued
by the very same issues. (Welcome to many-to-many
data relationships!)

So, instead of cataloging the tags (and which
files they have been applied to) or the files
(and which tags have been applied to them) I
decided to catalog the relationships themselves:
the edges between the nodes, with <==> separating
the tag name from the file name, one line per
association.

Yes, it takes a bit more space. Space-for-speed
(or vise-versa) is always a tradeoff. This format
should be pretty fast (and EASY) to parse though:
want to find all the files with a certain tag?
Use awk or grep. How about all tags applied to a
single file? Awk or grep. It's that simple.
Minor clean-up.
Make PyPI package.
Add some logging.
Enable test passage on Windows hosts.
Add build scripts.
Add Travis-CI build support.
Add Coveralls coverage reporting.
Add logo and update the readme
Add plural 'tags()' and 'untags()' functions.
Update build scripts.
Rename FORMAT to MAPPING
That's quite enough of that silly business.
Add error suppression to plural 'tags()' function
Add support for additional output file formats
Update format parameter to be optional