Proposal: Refactor metadata source search API: Source + SearchQuery with legacy fallback - #6943
Draft
semohr wants to merge 2 commits into
Draft
Proposal: Refactor metadata source search API: Source + SearchQuery with legacy fallback#6943semohr wants to merge 2 commits into
semohr wants to merge 2 commits into
Conversation
unifies `tag_album` and`tag_item` quite a bit. We might be able to combine the functions in the future.
|
Thank you for the PR! The changelog has not been updated, so here is a friendly reminder to check if you need to add an entry. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Modernizes the metadata source plugin search API:
candidates(items, artist, album, va_likely)→candidates(source, search_query)item_candidates(item, artist, title)→item_candidates(source, search_query)This PR keeps the legacy signatures working during the transition: the dispatch layer detects plugins that still implement the old API, converts the new arguments for them, and emits a deprecation warning. Nothing in any plugin (built-in or third-party) needs to change for beets to keep working.
Why
The old search signatures hand plugins a handful of derived strings. The new API gives plugins the full search context instead:
Source: the items themselves (for barcode/ISRC/catalog-number lookups), the consensus artist/album andva_likely, and ID consensus.SearchQuery: structured user-supplied search parameters, orNonewhen no manual search was requested.The old signature did not allow plugins to tell consensus values apart from user-supplied searches: the
artistandalbumstrings contained whichever was available, with no way to distinguish the two for plugins. This is, for example, an issue for Tidal, which checks for ISRCs and barcodes and uses them for lookups, which should not happen for manual search queries. This is currently impossible to detect.As an alternative, these IDs could be extracted in the core layer as well (similar to the mb/spotify/tidal IDs), but that would require the same amount of refactoring and likely changes to
albums_for_ids. A bit of a question how much control we want to give plugins during search.This is still work in progress: the docs need updating and some tests are currently broken. Before investing more time, I'd like to check whether we are happy with this approach as it will break the plugin api at some point!