I believe this fixes#4785, but I might be misunderstanding the
description and it might already be fixed.
Tagging @JOJ0 since they created both the bug linked above, and
5bf4e3d92f which mentions it.
Utilize a [new way of declaring
NamedTuples](https://docs.python.org/3/library/typing.html#typing.NamedTuple),
which allows for typechecking as well. Maybe the latter is now redundant
in other places, but I'm not that familiar with the codebase yet, so I
just changed the declarations (and hopefully used the correct types).
While I was at it, I also ran `poetry update`, but I'll revert
poetry.lock in case I wasn't supposed to do that. This is my first
commit here, so I hope I didn't do anything wrong...
As noted by 5bf4e3d92f, MusicBrainz
external IDs (`*_album_id`) were only saved for items and not albums.
This commit addresses that by copying `AlbumInfo` fields to the `Album`,
i.e. what's saved in the DB.
This is similar to how `TrackInfo` fields are copied to `Item` instances
except the copying is done at a different time since we only get an
`Album` much later in the import flow.
Fixes#5289 and #5185
Tried using the `autobpm` plugin and found a couple of issues:
1. #5185 `librosa` dependency was missing in `pyproject.toml`
2. Simply including the plugin in the configuration made `beet` take
over 4 seconds to start up.
3. BPM detection failed due to another missing dependency, `resampy`
4. #5289 Librosa `beat_track` function returned unexpected type which
made the plugin and the entire import process fail.
Addressed each of the above, slightly refactored the plugin and added
tests.
... continuing the test suite migration to `pytest` (#5361), this PR
replaces `unittest` method assertions with `assert` statement.
See the table below for a list of the replaced methods and their counts.
This should help clarify the size of the pull request 😆.
To keep things simple for the review, I have replaced each method in its
own commit. This
way, things should be easy to follow if you step through the commits one
by one. 🙂
method | count
--- | ---
**`assertEqual`** | 1747
**`assertIn`** | 200
**`assertTrue`** | 149
**`assertIsNone`** | 87
**`assertFalse`** | 85
**`assertRaises`** | 69
**`assertNotIn`** | 64
**`assertNotEqual`** | 39
**`assertIsNotNone`** | 35
**`assertIsInstance`** | 35
**`assertLessEqual`** | 23
**`assertGreater`** | 15
**`assertLess`** | 14
**`assertGreaterEqual`** | 14
**`assertAlmostEqual`** | 9
**`assertRaisesRegex`** | 4
**`assertCountEqual`** | 2
**`assertListEqual`** | 1
❗ Note that this *only* replaces methods provided by
`unittest` by default.
**Custom** assertion method replacements (like `assertExists` will be
addressed in a separate PR).
I surprisingly found that many queries for fields that exist in the
database are 'slow'. Querying items with `month:0` used a slow query
while `title:0` used a fast one.
I found the mistake in the logic: the field existence in the db check
was done *after* prepending the table name to the field. This meant that
the logic wrongly checked e.g. `items.field` instead of `field`.
This commit fixes the above and renames the variables for more clarity.
I surprisingly found that many queries for fields that exist in the
database are 'slow'. Querying items with 'month:0' used a slow query
while 'title:0' used a fast one.
I found the mistake in the logic: the field existence in the db check
was done *after* prepending the table name to the field. This meant that
the logic wrongly checked e.g. 'items.field' instead of 'field'.
This commit fixes the above and renames the variables for more clarity.
