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
The move functions in library.py and manipule_files in importer.py where
changed to use a single parameter for the file operation instead of
multiple boolean flags.
A typo in the documentation of the Album.move and Item.move functions
confusing True and False when describing the store parameter was fixed
as well.
The old tests were wrong but the incorrectness was hidden by the incorrect
parameter passing fixed in the previous commit. Now we actually test that the
item's path did not change.
Related to #1966. Previously, we used a `syspath` call inside MediaFile, which
probably wasn't right: the constructor should behave like `open` in that we
need to use pass an OS path.
This was a vestige from when we used to need the unittest2 library for pre-2.7
compatibility. Now that we require Python 2.7, we aren't using that library
and this indirection wasn't doing any good.
On my machine, the "leak" of other bash_completion scripts here recently
started doing a *lot* of work for other packages. Most damningly, it started
compiling a bunch of stuff with rustc! Now we only load beets' own completion
stuff.
This rolls back the places in #2094 where `six.text_type(s)` was used where
`s` might be a bytestring. We almost never want that conversion, because it
uses the default encoding (almost always ASCII). The need for it indicates a
problem somewhere else, where bytes were produced when we were expecting
unicode strings.
