External Python packages interfacing beets may want to use an in-memory
beets library instance for testing beets-related code.
The `TestHelper` class is very helpful for this purpose.
Previously `TestHelper` was located in the `test/` directory.
Now it is part of `beets` itself (`beets.test.helper.TestHelper`) and
can be easily imported.
The import path mangling is not relevant (anymore?) for the two
ways of running tests:
* `python3 test/testall.py` (see CONTRIBUTING.rst):
The `testall.py` script already adds the project path to `sys.path`.
* `tox -e py-cov`: this command is supposed to be run from the project
path. Thus, the current directory is already the first of location
in `sys.path`.
The previous mangling of the import path while loading a module could
lead to unwanted side-effects hidden in an unexpected location.
Instead, import path mangling should take place in the script being
called by the user (here: `testall.py`).
In cf69cad56f the Sphinx version was pinned to "<4.4.0".
The issue at that time (a spurious warning) is described in:
https://github.com/sphinx-doc/sphinx/issues/10112
The problematic check was removed in Sphinx v4.5:
https://www.sphinx-doc.org/en/master/changes.html#id334
The issue of spurious warnings was finally fixed in v5.x:
https://github.com/sphinx-doc/sphinx/pull/10137
Technically it would be suitable to add a negative version pin of Sphinx
for "4.4".
But that version is quite outdated and at least Debian never shipped
Sphinx v4.4 in a stable release.
We force sphinx to be at least v5 in order to fix an unrelated recent
compatibility requirement of `sphinxcontrib.applehelp`.
Do not let the web plugin overwrite the Content-Length header with the full file length since flask/werkzeug sets the requested range's/chunk's size when handling a range request.
This allows to play large audio/opus files using e.g. a browser/firefox or gstreamer/mopidy without making a reverse-proxy/nginx emulate range request support and hide range-related headers from the backend.
Beets web API already allows remote players to access audio files but it doesn't provide a way to expose the playlists defined using the smartplaylist plugin.
Now the smartplaylist plugin provides an option to generate ID-based item URIs/URLs instead of paths.
Once playlists are generated this way, they can be served using a regular HTTP server such as nginx.
To provide sufficient flexibility for various ways of integrating beets remotely (e.g. beets API, beets API with context path, AURA API, mopidy resource URI, etc), the new option has been defined as a template with an `$id` placeholder (assuming each remote integration requires a different path schema but they all rely on using the beets item `id` as identifier/path segment).
To prevent local path-related plugin configuration from leaking into a HTTP URL-based playlist generation (invoked with CLI option in addition to the local playlists generated into another directory), setting the new option makes the plugin ignore the other path-related options `prefix`, `relative_to`, `forward_slash` and `urlencode`.
Usage examples:
* `beet splupdate --uri-format 'http://beets:8337/item/$id/file'` (for beets web API)
* `beet splupdate --uri-format 'http://beets:8337/aura/tracks/$id/audio'` (for AURA API)
(While it was already possible to generate playlists containing HTTP URLs previously using the `prefix` option, it did not allow to generate ID-based URLs pointing to the beets web API but required to expose the audio files using a web server directly and refer to them using their file system `$path`.)
Relates to #5037
The boolean flags `--extm3u` and `--no-extm3u` are replaced with a string option `--output=m3u|m3u8`.
This reduces the amount of options and allows to evolve the CLI to support more playlist output formats in the future (e.g. JSON) without polluting the CLI at that point.
