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.
That's 371cc72f2d09 in hg. This makes the patch slightly more general by
reusing our type conversion infrastructure. It also uses "bytes" as a synonym
for "str" that I find a little bit clearer.
Otherwise, this was penalizing all album matches.
This also applies the same treatment as the previous commit: only load the
config at run time (at the expense of code clutter).
By running .get() (or, rather, .as_number()) in the module scope, this was
forcing the configuration to be materialized when the module was imported.
This is a little bit messier but requires a less duplication and avoids that
early loading problem.
I know the as_number calls scattered throughout are rather ugly; I'm pondering
a solution to mitigate that.
Basically, it uses the helpers that handle conversion bytestring <-> unicode with the item's path, but weren't being used with artpath. For now, it just fixes the behavior for `modify`
Discogs (and other individual plugins) should return a penalty between
0.0 and 0.1, which will be multiplied by the general source weight. This
allows individual plugins to be weighted against relative to each other,
and amplified together against other penalty categories (track, title,
etc.)
