WIP: Use vcrpy more widely, regenerate broken cassettes

[hseg]

[!NOTE] The scope of this PR has creeped since the initial posting. Additions are listed at https://github.com/spotDL/spotify-downloader/pull/2128#issuecomment-2208708687

test_matching: Use vcrpy to avoid being rate-limited by Spotify

Description

Among the network-based tests, test_matching has not been updated to use vcrpy. This makes it hit the Spotify API with every run, making the tests flaky. This patch series enables vcrpy on the test and uploads the cassettes that were generated with it.

Also, update test expectations for some tracks that now have more matches.

Related Issue

Closes: #2127

Motivation and Context

See above.

How Has This Been Tested?

Tests are running on a clean chroot with the following config:

platform linux -- Python 3.12.4, pytest-8.2.2, pluggy-1.5.0
rootdir: /build/spotdl/src/spotdl
configfile: pyproject.toml
plugins: typeguard-4.3.0, subprocess-1.5.0, mock-3.14.0, cov-5.0.0, asyncio-0.23.7, anyio-4.4.0, pyfakefs-5.5.0, recording-0.13.0
asyncio: mode=Mode.AUTO

(Specifically, I'm using Arch Linux's pkgctl to create a systemd-nspawn container with only the minimal dependencies needed to build the AUR package installed.)

Types of Changes

• [x] Bug fix (non-breaking change which fixes an issue)
• [ ] New feature (non-breaking change which adds functionality)
• [ ] Breaking change (fix or feature that would cause existing functionality to change)

Checklist

• [x] My code follows the code style of this project
• [ ] My change requires a change to the documentation
• [ ] I have updated the documentation accordingly
• [x] I have read the CONTRIBUTING document

• [ ] I have read the CORE VALUES document

  It doesn't exist?

• [ ] I have added tests to cover my changes

• [ ] All new and existing tests passed

  I am still getting these four failures, but these seem to be a bug in the YTMusic provider code (I suspect the "lookup by ISRC" code is dropping some matches) rather than a problem with the cassettes

  FAILED tests/test_matching.py::test_ytmusic_matching[https://open.spotify.com/track/6fyzS9YbkUhmEmJ52s19Ob-expected18] - AttributeError: 'NoneType' object has no attribute 'split'
  FAILED tests/test_matching.py::test_ytmusic_matching[https://open.spotify.com/track/4Ga9D6SHCVUNsOLPVSZf9v-expected19] - AttributeError: 'NoneType' object has no attribute 'split'
  FAILED tests/test_matching.py::test_ytmusic_matching[https://open.spotify.com/track/2w8C31hIPvJMPD4MDdNTro-expected28] - AttributeError: 'NoneType' object has no attribute 'split'
  FAILED tests/test_matching.py::test_ytmusic_matching[https://open.spotify.com/track/1ZEsqzNBQqyC7VLRTUDopj-expected33] - AttributeError: 'NoneType' object has no attribute 'split'

Moreover, when I run in a chroot, on the first run I get errors due to attempts to overwrite cassettes (even when running with --recording-mode=none --block-network) pytest-initial-chroot, pytestdebug-initial-chroot, and on subsequent runs I get YT-DLP download error in some cases pytest-later-chroot, pytestdebug-later-chroot. Outside the chroot, I sometimes get cassette-overwriting attempts pytest-cassette-system, pytestdebug-cassette-system, and sometimes only the four YTMusic errors above pytest-ytmusic-system, pytestdebug-ytmusic-system.

I don't know what's wrong with my setup that I'm getting these inconsistent results, but this is as far as my knowledge carries me.

[hseg]

Attempting to ignore the broken tests, I see the following are also not vcr'd:

• tests/test_init.py::test_get_urls
• tests/utils/test_m3u.py::test_create_m3u_content
• tests/utils/test_m3u.py::test_create_m3u_file
• tests/utils/test_search.py::test_parse_query

Besides those, I'm getting vcr.errors.CannotOverwriteExistingCassetteException on tests I haven't touched (eg in tests/utils/test_search.py) and possibly relatedly I'm getting requests.exceptions.ContentDecodingError due to incorrect gzip headers.

There are a couple more errors, but they're in a different vein, and hopefully by the time we get these errors settled the others will resolve themselves.

Logs: pytest-system pytestdebug-system pytest-chroot pytestdebug-chroot

[hseg]

In view of the above, I've added vcrpy invocations to the listed calls that are missing them. I've also regenerated the cassettes that were causing errors.

On my system, this reduces the total number of failed tests to 14:

• 4 from the broken cases in tests/test_matching.py::test_ytmusic_matching
• 5 due to #2058 (only on my system, not in chroot, since the chroot isn't configured for XDG)
• 1 due to a failed assertion in tests/utils/test_search.py::test_parse_yt_link (conjencturally, due to a failed network request, with the specific error masked by the assertion failure)
• 2 due to SystemExit: 1 in tests/console/test_entry_point.py (only on my system, not in chroot. No idea why)
• 2 tests for which I haven't yet managed to get a working cassette yet (am retrying once an hour until I'll get working cassettes, will force-update the "Regenerate cassettes" commit once I get the working cassettes)

pytest-chroot.log pytestdebug-chroot.log pytest-system.log pytestdebug-system.log

[hseg]

One cassette down, two to go. Though for some reason I've picked up a test failure in tests/utils/test_ffmpeg.py::test_convert on my system and flakily have picked up another in tests/utils/test_metadata.py::test_embed_metadata in my chroot -- not clear what's going on there.

[hseg]

Turns out tests/utils/test_ffmpeg.py::test_download_ffmpeg makes network requests as well. The cassette it generates is 110M, which is larger than Github's default maximal file size. I've commented it out for now to support users who are testing with --block-network, though this should probably be set to skip with --block-network set.

Moreover, I'm puzzled by the fact we have this function in the first place. If we're so concerned users won't be able to install ffmpeg properly on their machines, shouldn't we just provide binaries with ffmpeg bundled in? (leaving aside the problematic nature of such private dependencies). This might have GPL implications, though -- we'd need to check if it's enough to just attribute and link to the ffmpeg source or if we need anything more extensive.

[hseg]

Yet another function found:

• tests/test_init.py::test_download