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.
PEP 414 didn't add `ur"..."` literals to Python 3. So for hybrid 2/3
compatibility, these had to be replaced with ordinary Unicode string literals.
This was only painful for one string; the others were only raw strings by
convention. (All were regexes.)
This reverts commit 9c41c39913.
That commit used byte strings for the `if __name__ == '__main__'` pattern,
which was necessary when we were doing unicode_literals. But it is wrong on
Python 3, and now that we're liberated from unicode_literals, we need to go
back to native strings for this comparison.
I found some infelicities while investigating #1826. This test was hard-coding
a specific path for bash-completion, which was the wrong one for my system, so
it was being skipped every time. This searches the list of paths used by the
actual command.
When setting format and using --album we *need* to know whether we're in
album mode. Naively if --album happens after "--format fmt" then we'll
set Item format instead of Album format.
By looking forward for -a/--album we bypass that problem.
Include import of __future__ features division, absolute_imports and
print_function everywhere. Don't add unicode_literals yet for it is
harder to convert.
Goal is smoothing the transition to python 3.
The logic of setting up beets and running a command was scattered
across the `_raw_main` and `_configure` functions. This is an attempt
to bring more structure to the process and to diminish the dependency
on global state.
Doing test-specific cleanup in tearDown before general sandbox deletion helps
avoiding contamination of global state between tests when cleanup fails.
Current Windows status:
Ran 1106 tests in 72.373s
FAILED (SKIP=10, errors=13, failures=15)
Closer!
This puts the OrderedEnum generic class next to where it is actually used. It
also refers to the recipe it is taken from on docs.python.org. I also took the
opportunity to give this a capitalized name (since it's a proper type).
Bash 3.2 does not have associative arrays, so we hack around that by using
generic varibale names like `opts__$cmd`. We also don't support the "?" alias
anymore.
The command prints a shell script that provides completion for the `beet`
command. To test it run `eval "$(beet completion)"` in your shell.
I also included some crude testing for this. The `test/test_completion.sh`
script runs tests in a shell and exit with a non-zero status code if the tests
fail. It assumes that the completion script is already loaded in the executing
shell.
As of now the completion only works for bash 4.1 and newer.
Beets stores all its data in the `BEETSDIR` directory. The default is
determined by the system:
* `%APPDATA%\beets` on Windows. If the `APPDATA` environment variable is
not set it falls back to `~\AppData\Roaming\beets`.
* `$XDG_CONFIG_DIR/beets` on UNIX. If the `XDG_CONFIG_DIR` environment
variable is not set it falls back to `~/.config/beets`
* `~/Library/Application Support/beets` on OSX
The default can be overwritten using the `BEETSDIR` environment variable.
The user configuration is read from `$BEETSDIR/config.yaml`. Additional
configuration files that overwrite options from the user configuration may
be specified using the `--config` command line options.
All relative paths in any configuration are resolved relative to `BEETSDIR`.
The new Distance object knows how to perform various types of distance
calculations (expression, equality, number, priority, string).
It will keep track of each individual penalty that has been applied so
that we can utilise that information in the UI and when making decisions
about the recommendation level.
We now display the top 3 penalties (sorted by weight) on the release
list (and "..." if there are more than 3), and we display all penalties
on the album info line and track change line.
The implementation of the `max_rec` setting has been simplified by
removing duplicate validation and instead looking at the penalties that
have been applied to a distance. As a result, we can now configure a
maximum recommendation for any penalty that might be applied.
We have a few new checks when calculating album distance:
`match: preferred: countries` and `match: preferred: media` can each be
set to a list of countries and media in order of your preference. These
are empty by default. A value that matches the first item will have no
penalty, and a value that doesn't match any item will have an unweighted
penalty of 1.0.
If `match: preferred: original_year` is set to "yes", beets will apply
an unweighted penalty of 1.0 for each year of difference between the
release year and the original year.
We now configure individual weights for `mediums` (disctotal), `label`,
`catalognum`, `country` and `albumdisambig` instead of a single generic
`minor` weight. This gives more control, but more importantly separates
and names the applied penalties so that the UI can convey exactly which
fields have contributed to the overall distance penalty.
Likewise, `missing tracks` and `unmatched tracks` are penalised and
displayed in the UI separately, instead of a combined `partial` penalty.
Display non-MusicBrainz source in the disambiguation string, and
"source" in the list of penalties if a release is penalised for being
a non-MusicBrainz.
The 'decode' call fails in what is already a unicode string. I'm not
sure under what circumstances the string is or isn't unicode (apparently
it varies), so I added a check. The test passes with the patch, at
least.
This allows matches to indicate both missing and unmatched tracks in their
candidates and solves some of the spaghetti tuples that were passed around
during autotagging.
In an attempt to finally address the longstanding SQLite locking issues, I'm
introducing a way to explicitly, lexically scope transactions. The Transaction
class is a context manager that always fully fetches after SELECTs and
automatically commits on exit. No direct access to the library is allowed, so
all changes will eventually be committed and all queries will be completed. This
will also provide a debugging mechanism to show where concurrent transactions
are beginning and ending.
To support composition (transaction reentrancy), an internal, per-Library stack
of transactions is maintained. Commits only happen when the outermost
transaction exits. This means that, while it's possible to introduce atomicity
bugs by invoking Library methods outside of a transaction, you can conveniently
call them *without* a currently-active transaction to get a single atomic
action.
Note that this "transaction stack" concepts assumes a single Library object per
thread. Because we need to duplicate Library objects for concurrent access due
to sqlite3 limitation already, this is fine for now. Later, the interface should
provide one transaction stack per thread for shared Library objects.
Instead of parsing the template at each call to destination(), it's now possible
to parse them *once*, a priori, and re-use the resulting template object. This
is analogous to the re module's compiled expressions.
