The Library object is now (almost) safe to share across threads. Per-thread
resources are now automatically managed internally. There is no longer any need
for the _reopen_lib hack to get multiple copies of the Library object.
This is the first of several commits that will modernize the beets codebase for
Python 2.6 conventions. (Compatibility with Python 2.5 is hereby abandoned.)
This commit makes rewrite explicitely match items using the .lower() function
instead of using Pythons builtin re.I flag.
This is required as the re.I flag only allows for case-independent pattern
matching with ascii chars. Even worse, the pattern is stored in lowercase when
using re.I, but the value to be matched isn't lowercased.
Example:
[rewrite]
artist Сергей Васильевич Рахманинов: Sergei Rachmaninoff
In an attempt to finally address the longstanding SQLite locking issues, I'm
introducing a way to explicitly, lexically scope transactions. The Transaction
class is a context manager that always fully fetches after SELECTs and
automatically commits on exit. No direct access to the library is allowed, so
all changes will eventually be committed and all queries will be completed. This
will also provide a debugging mechanism to show where concurrent transactions
are beginning and ending.
To support composition (transaction reentrancy), an internal, per-Library stack
of transactions is maintained. Commits only happen when the outermost
transaction exits. This means that, while it's possible to introduce atomicity
bugs by invoking Library methods outside of a transaction, you can conveniently
call them *without* a currently-active transaction to get a single atomic
action.
Note that this "transaction stack" concepts assumes a single Library object per
thread. Because we need to duplicate Library objects for concurrent access due
to sqlite3 limitation already, this is fine for now. Later, the interface should
provide one transaction stack per thread for shared Library objects.
Instead of parsing the template at each call to destination(), it's now possible
to parse them *once*, a priori, and re-use the resulting template object. This
is analogous to the re module's compiled expressions.
User can specify a fixed name (eg *import.m3u*) by setting the `m3u_fixedname`, otherwise a dynamic m3u filename will be generated base on the imported items (album/track title).
This is accomplished via a new event, "import_task_apply", which is called
right after metadata is applied to newly-imported items.
This change makes chroma REQUIRE a new version (0.6) of pyacoustid. Users with
older versions installed will see complaints about a missing method
"fingerprint_file".
The old "caching"-based approach to fingerprinting was kinda hacky to begin
with. Now, the chroma plugin has an explicit opportunity (in the form of a new
event) to perform its initial fingerprinting and lookup for all tracks. Then,
this information is used explicitly during the autotagging phase rather than
being used transparently through memoization of the lookup function.
