Although crossfade is not implemented in bpd, we can store the setting
and repeat is back to clients. Also log a warning that the operation is
not implemented.
The real MPD doesn't show the crossfade in status if it's zero since
that means no crossfade, so now we don't either.
The test `CommonOptionsParserCliTest.test_version` was passing with nose
but failing with pytest (see output below). The reason for the failure
seemed to be that the `test` plugin was loaded when it wasn't expected
to be loaded, changing the output of the `version` command. I'm not sur
exactly why that was happening, but since that test already inherited
from `TestHelper`, just invoking the plugin load/unload helper was
enough to fix it. I also removed the line setting the `self.lib`
variable since that's already done in the helper.
---
self = <test.test_ui.CommonOptionsParserCliTest testMethod=test_version>
def test_version(self):
l = self.run_with_output(u'version')
self.assertIn(u'Python version', l)
> self.assertIn(u'no plugins loaded', l)
E AssertionError: 'no plugins loaded' not found in 'beets version 1.4.8\nPython version 3.7.3rc1\nplugins: test\n'
test/test_ui.py:1292: AssertionError
Since Python 3.3 the abstract base classes from `collections` are moved
to the `collections.abc` module. From Python 3.8 they will be
unavailable from their original location.
https://docs.python.org/3/library/collections.abc.html
Previously the `the` plugin would log a debug message when the text _didn't_ get changed by the plugin, whereas I think what was intended was the opposite. With this change the logged messages show the actual transformations made by the plugin.
Decode the bytes to strings: the MPD protocol specifies that the
communications are all in UTF-8.
Also parse the body into a dict since this is typically more convenient
than having to do it manually in each test.
The BOD tests are currently forking a process with a server running, and
this attempts to close stdin. Tests were failing due to DummyIn not
implementing the close() method. Adding this simple no-op does the trick
to allow forking and seems like a harmless addition.
The MPD protocol allows batching commands. There are two choices for the
first message that announced a batch is starting, and we just go for the
one that causes the server to respond with a marker message between each
individual response, since that's easier. This might need to be tweaked
in order to test the behaviour with the other batch indicator.
MPD now supports more fields ("tags") than what BPD advertises. Fixing
this should be a simple task of extending the mapping of fields to tags
in BPD's implementation.
The current MPD spec is several versions ahead of BPD. These tests just
compare the full specified list of commands against what BPD claims to
support (without actually testing their implementations). It's handy as
a measure of progress against the specification, but can perhaps be
dropped later once all of the individual protocol methods have tests.