Unfortunately tox does not play very nicely with Poetry. Tox was mostly
useful since it managed virtual environments, however now this is done
by Poetry.
Thus we do not anymore need it since we can run our commands using
`poetry run`. I have extended the internal helper tool 'project' with
those commands that have previously been run using tox.
In #4746 I was making a small adjustment in beetsplug/aura.py and found
that the module wasn't tested. So this PR adds some high-level tests to
act a safeguard for any future adjustments.
The docs say:
> The `auto` option uses reflinks when possible and falls back to plain
> copying when necessary.
I've been using this option for a while, and recently discovered that
despite the option, copying fails between two BTRFS filesystems with:
Error: OS/filesystem does not support reflinks. during link of paths /mnt/fs1/file, /mnt/fs2/file
I tracked this down to how the configuration is handled in the importer.
Additionally, update the 'in progress' header in the changelog: instead
of using a specific version number, simply say 'Unreleased' since we do
not know in advance what version will the changes be eventually
released.
This also simplifies latest changelog retrieval.
Looking at the logs, it's using the ref before the one that increments
the version in the previous action in the workflow. This code is from
https://github.com/actions/checkout/issues/439#issuecomment-965968956
and supposedly fixes this by making it pull specifically from master,
rather than the ref that the workflow was called on.
## Description
Fixes#5222.
Drop Python 3.7. `pyupgrade` is responsible for most of the changes in
the code. I undid some of the bits it attempted to update that aren't
strictly necessary:
1. Converting `List/Dict/Tuple` -> `list/dict/tuple` in modules that
have `from __future__ import annotations` import. This should be done in
a separate PR, and for all modules
2. Converting some `.format(` calls to f-strings. It didn't do it
consistently, and it should also be done in a separate PR, I believe.
Python upgrade unblocks several other PRs, for example #5266 and #5248.
Rigth now it creates something like:
```
.../Perota Chingo/Un viajecito/.12 Rie Chinito.flac64u8gm5u.beets
```
where no separatio between temp name and file extention, and it makes
quite hard to read it.
So, this changes adjust name to
```
.../Perota Chingo/Un viajecito/.12 Rie Chinito.flac.64u8gm5u.beets
```
This was one of forgotten fixup from
8d50301be5
Rigth now it creates something like:
```
.../Perota Chingo/Un viajecito/.12 Rie Chinito.flac64u8gm5u.beets
```
where no separatio between temp name and file extention, and it makes quite hard to read it.
So, this changes adjust name to
```
.../Perota Chingo/Un viajecito/.12 Rie Chinito.flac.64u8gm5u.beets
```
This was one of forgotten fixup from 8d50301be5
I humbly present a solution our lack of releases: a workflow that can be
triggered to automatically create one. This workflow builds the project,
creates a GitHub release, and publishes beets to PyPi, for a one-stop
solution.
@sampsyo this would make it much easier to create releases, as it
requires only one little interaction: going to the actions tab and
entering a version number. Once that's done, the workflow should take
care of the rest.
I have only tested the `build` job so far, since I can't do anything
about the pypi or do a release just to test, but the code is lifted from
other similar actions and should work fine.
It also requires one piece of setup. This is that PyPi must be set up
with a [trusted publisher](https://docs.pypi.org/trusted-publishers/) to
receive the new package. Once that's done, the process should go off
automatically.
This will be help with testing each of the documents which do not
any more depend on the 'global' `current_app` and `request`. These two
can now be provided at the time the objects are instantiated.
Add `pytest-cov` which automatically measures coverage while tests are
executing and update tox and ci build configuration accordingly.
Add configuration for coverage:
1. Enable analysing logical branches
2. Save coverage details as HTML for local development use
3. Configure the HTML output to include coverage context: on the
right-hand side of each covered code line there is an expandable
section which lists every test that ran that line.
Enforce the same interface across all `...Query` implementations
### Make `PlaylistQuery` a `FieldQuery`
While working on the DB optimization and looking at updates upstream I discovered one query which does not follow the `FieldQuery` interface —`PlaylistQuery`, so I looked into it in more detail and ended up integrating it as a `FieldQuery`.
One special thing about it is that it uses **IN** SQL operator, so I added implementation for this sort of query outside the playlist context, see `InQuery`.
Otherwise, it seems like `PlaylistQuery` is a field query with a special way of resolving values it wants to query. In the future, we may want to consider moving this kind of custom _initialization_ logic away from `init` methods to factory/@classmethod: this should make it more clear that the purpose of such logic is to resolve the data that is required to define a particular `FieldQuery` class fully.
### Remove `NamedQuery` since it is unused
This simplifies query parsing logic in `queryparse.py`. We know that this logic can only receive `FieldQuery` classes thus I adjusted types and removed the logic that handles other cases.
Effectively, this means that the query parsing logic does not need to care whether the query is named by the corresponding DB field. Instead, queries like `SingletonQuery` and `PlaylistQuery` are initialized with the same data as others and take things from there themselves: in this case they translate `singleton` and `playlist` queries to the underlying DB filters.
