* Use full name for musicbrainzngs import
* Use beets internal logging facilities
* Match releases by release id
* Convert some strings to Unicode
* Remove unnecessary MB rate-limiting
* Remove unnecessary imports
* Follow beets convention for `--album` option
* Follow beets convention for imperative docstrings
* Simplify method signatures
* Use defaultdict(list) where appropriate
* Clarify missing MBID log message
Signed-off-by: Quentin Young <qlyoung@qlyoung.net>
Code now relies on `format()` for items and albums displaying/logging.
`ui.print_()` calls `unicode()` or `str()` on the strings so for most
usages calling `ui.print_(obj)` replaces `ui.print_(obj, lib, None)`.
Where there is a special format `ui.print_(format(obj, fmt))` is fine,
but when `fmt` can be None then one has to call
`ui.print_(ui.format_(obj, fmt))` -- which is what `ui.print_obj` now
does.
This fixes tracktotal being stored incorrectly for multi-disc releases
where the individual discs have a different number of tracks and
per_disc_numbering is enabled.
Include import of __future__ features division, absolute_imports and
print_function everywhere. Don't add unicode_literals yet for it is
harder to convert.
Goal is smoothing the transition to python 3.
Releases can consist of discs of various media types, most typically
CD/DVD combo releases. Having the media value an album level field
forces all discs to be of the same type. Making it an item level
field instead seems to be the proper thing to do here.
Fixes#161
As outlined in #299, we broke many places in the code that were expecting
_album_for_id and _track_for_id to return a single item rather than a list. I
took this opportunity to divide up the interface: there's now one function for
MBIDs (returning a single object or None) and one for generic IDs (returning a
list).
It's possible that these plugins might require a little more thought
into how they should work (or not work) with potentially multiple albums
matching an idea, and potentially those those albums being an incorrect
match (e.g. if two data source plugins share a simple numerical ID
format).
An earlier change (due to @pedros) added the ability for plugins to define
template fields that work with Albums as well as Items. This enables some
cool new use cases but required that every template field definition check the
type of its arguments. Instead, this iteration on the idea distinguishes
between fields meant for Items and those meant for Albums.
In addition to simplifying the implementation of these functions, this also
enables the creation of album fields with identical names to item fields.
(For example, a user contacted me recently about adding a $bitrate field for
albums, which would be the average bitrate of the items. They can do this now
using a plugin.)
I also changed the docs to stop using the decorator approach to registering
template fields. We're moving toward removing those.
