### b5216a0 is a proposed fix for #5218
We don't assume anymore that if the pattern lacks the "artist" group it
also has the "title" group (this was causing the "title" KeyError, when
the pattern containg only the `?P<track>` group is used).
Instead, we check for existence of "title" before assigning
"title_field", otherwise we let the last pattern (which will always
match) to assign it. The only slight drawback is that files like
"01.mp3" will also get "01" as title (besides the "1" track number),
instead of having no title, but I guess that is not going to cause any
major problem in the rest of the import procedure (e.g. track matching
after a search). On the other hand, I guess allowing a file to have no
title would require a substantial rewriting of the plugin, since the
empty string is in BAD_TITLE_PATTERNS.
### 0966042 adds a log message about the pattern being tried
This is useful while debugging changes to the regexps in PATTERNS.
I used loglevel "debug" for this message, should we use "debug" also for
other messages (currently using level "info")?
### e6b7735 refactors the regexps in PATTERNS
I reviewed the regexps (especially after the changes I made some time
ago in 84cf336) and tried to make them cleaner.
- Allow " - " and "-" as separator between track/artist/title fields:
that should cover two common filename conventions: using spaces (e.g.
`01 - Artist Name - Title of the song`) or not using spaces (e.g.
`01-artist_name-title_of_the_song`). Some regexp groups are non-greedy,
to avoid capturing unwanted leading/trailing spaces in artist/titles; we
could think about some other enhancements, e.g. automatically converting
underscores to spaces in artist/title names, but I guess the main use of
the plugin is not to produce a perfectly formatted title, but a
sufficient meaningful one to be used as reference in the following
stages of the update procedure.
- Allow `?P<tag>` groups by making them optional in the first two
patterns (instead of having two versions of the pattern, with or without
tag). BTW I'm not sure what these groups are about: we optionally check
for them in the plugin, but we never use them to assign any metadata.
- Allow optional "." after the track number
- In the third pattern: also allow "_" as separator (e.g. for file names
like `01_some_tack.mp3`)
Implements #3354, updates #6040. This PR also improves typehints for the discogs plugin.
The name variations provided by Discogs can now be used by the
auto-tagger through 3 config options.
By default, the plugin will write the variation to the tag
`artist_credit`, but through three config options can also write it
to the album artist tag, the track's artist tag, or any combination of
the three.
This PR contains a small addition on #6040, letting the string used to
join featured artists be customized.
The new configuration options available, and their defaults, are as
follows:
```yaml
discogs:
featured_string: "Feat."
anv:
artist_credit: True
album_artist: False
artist: False
```
Make it obvious when beets is installed from from a non
major version. When installed locally this adds a git hash suffix and
the distance to the last release.
closes#4448
This PR moves the `vfs.py` module, which is only used by plugins, to
avoid polluting the main beets namespace. Also exposes the `vfs` and
`art` module from beets with a deprecation warning.
This PR enhances `beets/logging.py` with improved typing and tests:
* `getLogger` now returns the precise logger type (`BeetsLogger` or
`RootLogger`).
* Tests use `pytest` and `parametrize` for more concise and readable
coverage.
Fixes#6033
This PR addresses a bug where plugin loading failed when plugins
imported other `BeetsPlugin` classes, namely `chroma` and `bpsync`.
- Add module path filtering to ensure only classes from the target
plugin module are considered, preventing conflicts when plugins import
other `BeetsPlugin` classes