When creating a hardlink, either during import or `beet convert`, if the
origin of the hardlink was a symlink, that symlink used to be directly
copied. This could create broken symlinks if the origin symlink was
relative, and in either case, probably wasn't the user's desired
behavior.
This change de-references all symlinks before creating a hardlink, such
that the end result is a normal file with the same inode as the original
file. See #5676 for more discussion about the original issue.
Fixes#5676
As per #5652, `beet --config <path> config -e` edited the default config
path, even though that's not the config that would be used by beets.
It seems like this was the result of a deliberate short-circuit in
[`_raw_main()`](c2de6feada/beets/ui/__init__.py (L1832)).
The short-circuit prevents malformed configs from causing a crash before
opening the editor, but also prevents the setup function from loading
the custom config at all.
The solution used here is to just expose the CLI options to
`edit_config()`, so that it can use the custom config path if its set. I
also suspect that the branch in
[`config_func()`](c2de6feada/beets/ui/commands.py (L2354))
which is getting short circuited is actually unreachable, but I left it
in with a note just in case.
Fixes#5652
## To Do
- [x] ~~Documentation~~ (N/A)
- [X] Changelog
- [X] Tests
## Description
This one’s a big one 🎣 Proceed with care and a bit
of time ;)
The `ui/commands.py` file had grown into an unwieldy monolith (2000+
lines) over time, so this PR breaks it apart into a modular structure
i.e. **one file per command**, plus some cleanup and reorganization
along the way.
---
### What changed
* **Commands modularized:**
Every command (`help`, `list`, `move`, `update`, `remove`, etc.) now
lives in its own file under `ui/commands/`.
* **Support code reorganized:**
* Utility functions moved into a separate helper module.
* `commands.py` converted into `commands/__init__.py` for better import
handling.
* The `import` command (and related helpers) moved into its own folder:
* `importer/session.py` for import session logic
* `importer/display.py` for display-related functions
* **Tests cleaned up:**
* Each command’s tests now live in their own file.
* All UI-related tests were moved into a dedicated folder for clarity.
Moved tests related to ui into own folder.
Moved 'modify' command tests into own file.
Moved 'write' command tests into own file.
Moved 'fields' command tests into own file.
Moved 'do_query' test into own file.
Moved 'list' command tests into own file.
Moved 'remove' command tests into own file.
Moved 'move' command tests into own file.
Moved 'update' command tests into own file.
Moved 'show_change' test into test_import file.
Moved 'summarize_items' test into test_import file.
Moved 'completion' command test into own file.
Moved commands.py into commands/__init__.py for easier refactoring.
Moved `version` command into its own file.
Moved `help` command into its own file.
Moved `stats` command into its own file.
Moved `list` command into its own file.
Moved `config` command into its own file.
Moved `completion` command into its own file.
Moved utility functions into own file.
Moved `move` command into its own file.
Moved `fields` command into its own file.
Moved `update` command into its own file.
Moved `remove` command into its own file.
Moved `modify` command into its own file.
Moved `write` command into its own file.
Moved `import` command into its own folder, more commit following.
Moved ImportSession related functions into `importer/session.py`.
Moved import display display related functions into `importer/display.py`
Renamed import to import_ as a module cant be named import.
Fixed imports in init file.
## Description
Adds the new `mbpseudo` plugin, that proactively searches for pseudo-releases during import and
adds them as candidates. Since it also depends on MusicBrainz, there are
some special considerations for the default logic (which is now a plugin
as well). However, at the very least it expects a list of desired [names
of scripts](https://en.wikipedia.org/wiki/ISO_15924) in the
configuration, for example:
```yaml
mbpseudo:
scripts:
- Latn
```
It will use that to search for pseudo-releases that match some of the
desired scripts, but will only do so if the input tracks match against
an official release that is not in one of the desired scripts.
## Standalone Usage
This would be the recommended approach, which involves disabling the
`musicbrainz` plugin. The `mbpseudo` plugin will manually delegate the
initial search to it. Since the data source of official releases will
still match MusicBrainz, weights are still relevant:
```yaml
mbpseudo:
source_weight: 0.0
scripts:
- Latn
musicbrainz:
source_weight: 0.1
```
A setup like that would ensure that the pseudo-releases have slightly
more preference when choosing the final proposal.
## Combined Usage
I initially thought it would be important to coexist with the
`musicbrainz` plugin when it's enabled, and reuse as much of its data as
possible to avoid redundant calls to the MusicBrainz API. I have the
impression this is not really important in the end, and maybe things
could be simplified if we decide that both plugins shouldn't coexist.
As it is right now, using both plugins at the same time would still
work, but it'll only avoid redundancy if `musicbrainz` emits its
candidates before `mbpseudo`, ~which is why I modified the
plugin-loading logic slightly to guarantee ordering. I'm not sure if you
think this could be an issue, but I think the `musicbrainz` plugin is
also used by other plugins and I can imagine it's good to guarantee the
order that is declared in the configuration?~
If the above is fulfilled, the `mbpseudo` plugin will use listeners to
intercept data emitted by the `musicbrainz` plugin and check if any of
them have pseudo-releases that might be desirable.
Spotify has deprecated many of its APIs that we are still using, wasting
calls and time on these API calls; also results in frequent rate limits.
This PR introduces a dedicated `AudioFeaturesUnavailableError` and
tracks audio feature availability with an `audio_features_available`
flag. If the audio-features endpoint returns an HTTP 403 error, raise a
new error, log a warning once, and disable further audio-features
requests for the session.
The plugin now skips attempting audio-features lookups when disabled
(avoiding repeated failed calls and rate-limit issues).
Also, update the changelog to document the behavior.
## To Do
- [x] Changelog. (Add an entry to `docs/changelog.rst` to the bottom of
one of the lists near the top of the document.)
Add a dedicated AudioFeaturesUnavailableError and track audio-features
availability with an audio_features_available flag. If the audio-features
endpoint returns HTTP 403, raise the new error, log a warning once, and
disable further audio-features requests for the session. The plugin now
skips attempting audio-features lookups when disabled (avoiding repeated
failed calls and potential rate-limit issues).
Also update changelog to document the behavior.
