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.
