No MusicBrainz special case for disambiguation

[ghbrown]

When using multiple data sources for autotagging the disambiguation string contains the name of the data source (Spotify, Discogs, etc.) unless the source is MusicBrainz.

Candidates:
1. Dave Clarke - Remixes & Rarities 1992-2005 (77.6%) (id, tracks) (Vinyl, ...)
2. Dave Clarke - Remixes & Rarities 1992-2005 (72.8%) (id, tracks) (Discogs, Vinyl, ...)
                                                                        ^
                                                                        |
                                              disambiguation string ----

Since beets now handles many sources, it would be great to remove this special case handling of MusicBrainz in the disambiguation string.

My proposed fix is to print every data source when the user is using multiple data sources simultaneously, and not to print any data sources to the disambiguation string when there is only one data source. Therefore, the simplest case of a user using only MusicBrainz would remain unchanged. This behavior could be implemented as a one line change here so long as it's already possible to determine the total number of data sources being used from the config.yaml.

Alternatively, we could just remove the special case for MusicBrainz and always have the data source included at the front of the disambiguation string. To me this is less elegant than the above, but still preferable to the current state.

[sampsyo]

Sure; that's a good idea! One loose end to figure out would be: how do we know when the user is "using" multiple data sources? The options, as I see them, include:

1. Detect which plugins are registered, i.e., which sources the user has enabled at all.
2. Detect which sources provided the matches for the current import, i.e., whether those sources actually did anything for the current list of matches.

I think the first is obviously the better user experience, because it's more predictable (the disambiguators don't just suddenly seem to disappear/reappear for some matches). However, we don't currently have a convenient way to list all the enabled data sources, so the latter would be easier to implement.

[ghbrown]

The first is exactly what I had in mind, I was hoping the infrastructure for determining the number of active sources might already be in place. It shouldn't be too tough to implement something that works, but I'm not sure the best way to make it robust.

In my mind the pseudocode is

# near config parsing
known_sources = ['musicbrainz', 'discogs', 'spotify', ...] # hardcoded list of known sources as strings
used_plugins = <get list of all plugins used, don't forget to include musicbrainz>
enabled_sources = []
for used_plugin in used_plugins:
    if (used_plugin in known_sources) and used_plugin.is_enabled():
        enabled_sources.append(used_plugin)
n_sources = len(enabled_sources) # number of enabled sources

# in ui/commands.py
if info.data_source and (n_sources > 1):
    disambig.append(info.data_source)

Some caveats here include me not knowing how the config is parsed, how to determine if a plugin is enabled (I called a bogus method on string used_plugin to get my idea across), and how this information would be propagated to ui/commands.py.

The main robustness issue I see is having to update the hardcoded string, but that probably won't have to happen very often anyway. Perhaps this could be avoided by adding a field to a plugin class stating whether it's a data source, etc. but that's more drastic.