beetbox / beetbox/beets

`field:=value` in `paths:` config queries behaves inconsistently with `ls` for aggregate fields

Open
#5,108 1 comment 0 reactions 0 assignees View on GitHub
Dominant language
Python
Stars
15.7k
Forks
2.1k
Avg merge
4d 21h
Merged PRs (30d)
31

Description

### Problem

If I have the following `paths` config:

```yaml
paths:
albumtypes:=ep: "foo"
default: "bar"
```

and an item in my library with the albumtypes `ep` and not named `bar`, then `beet mv -p albumtypes:=ep` will try to name it `bar`.

### Setup

* OS: Exherbo Linux
* Python version: 3.11.5
* beets version: 1.6.1 (git 7f1250dd0a286b099d032fe65d1c287b0ed37d46)
* Turning off plugins made problem go away (yes/no): no

My configuration (output of `beet config`) is: very long, and not relevant (I tested the minimized case)

I was able to track this down somewhat - the stack (and relevant variables) looks like this:

- [`parse_query_string('albumtypes:=ep', library.Item)`](https://github.com/beetbox/beets/blob/7f1250dd0a286b099d032fe65d1c287b0ed37d46/beets/library.py#L1070), returning `(AndQuery([MatchQuery('albumtypes', 'ep', fast=True)]), NullSort())`
- [`item.destination(basedir=None)`](https://github.com/beetbox/beets/blob/7f1250dd0a286b099d032fe65d1c287b0ed37d46/beets/library.py#L1042)
- [`move_items(lib, None, ['albumtypes:=ep'], False, False, True, False, False)`](https://github.com/beetbox/beets/blob/7f1250dd0a286b099d032fe65d1c287b0ed37d46/beets/ui/commands.py#L2123)
- [`move_func(lib, opts, args)`](https://github.com/beetbox/beets/blob/7f1250dd0a286b099d032fe65d1c287b0ed37d46/beets/ui/commands.py#L2202) with `opts.pretend` and `args = ['albumtypes:=ep']`

Note that return value - this _fails_ to succeed in the subsequent `.match()`, while `(AndQuery([MatchQuery('albumtypes', ['ep'], fast=True)]), NullSort())` succeeds (adding square brackets around the value).

The search to gather the items, meanwhile, goes via a completely different path - it passes down to the database, and never goes through `.match()` at all.

I can see two ways of addressing this - one would be to make `parse_query_string` consider field types when deciding how to parse the value of a match; the other would be to make `match` for `MatchQuery` transform both sides into some "canonical form" (e.g. semicolon-separated list-in-string, for `albumtypes`) on a field-dependent basis.

Contributor guide

Open the contributing guide

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.