Highlights:
* We now have a beets-unstable
* We now run tests for beets-minimal
* We're much more strict about the effects of enabling/disabling plugins
* All patches but one were dropped
* Removal of deprecated nose in favor of pytest
* Art resizing is working better now
Refresh patches, remove keyfinder patch as upstream seems to use the
correct keyfinder-cli path, since:
https://github.com/beetbox/beets/pull/3467/files
Remove the doing nothing `imagemagick` in `buildInputs` and add a patch
that makes `beets` use `magick` from Nix' path. The patch can be
disabled along with the reference to imagemagick if it's set to `null`.
Formatting: use 1 line per input.
Remove the unevaluated externalTestArgs.beets - it was moved to
`all-packages.nix`.
Instead of managing external plugins in the beets derivation, we
introduce a new top-level package set beetsExternalPlugins which the
beets derivation receives as an input. This change doesn't affect how
the beets derivation is built or overridden, so the change won't be
noticed by users, but it makes hydra evaluate and build external plugins
which should benefit users of those plugins and prevent future
regressions as we have experienced (currently on master
beets-alternatives fails to evaluate, but this wasn't picked up by
ofborg nor hydra).
The maintainer has stopped cutting releases[1]. Since the last release,
1.4.9, includes a dependency that is filled with hate speech[2] it's all
the more reason to package the unstable version and eliminate that
requirement.
Moreover a number of fixes, improvements, and features have landed
since.
[1]: https://github.com/beetbox/beets/issues/3625
[2]: https://github.com/NixOS/nixpkgs/pull/90504
Co-authored-by: Doron Behar <doron.behar@gmail.com>
After making `ffmpeg` point to the latest `ffmpeg_4`, all packages that
used `ffmpeg` without requiring a specific version now use ffmpeg_3
explicitly so they shouldn't change.
Whenever we create scripts that are installed to $out, we must use runtimeShell
in order to get the shell that can be executed on the machine we create the
package for. This is relevant for cross-compiling. The only use case for
stdenv.shell are scripts that are executed as part of the build system.
Usages in checkPhase are borderline however to decrease the likelyhood
of people copying the wrong examples, I decided to use runtimeShell as well.
Since 0f38d9669f, the default Python
version for Python 3 is now Python 3.7.
It has been a while since beets had a new release, but the fix for
Python 3.7 is already in master (and it's also rather small), so I
decided to cherry-pick the commit as a patch.
I've built the package along with its tests and they failed at first,
but the errors were unrelated. So I disabled the tests for pylint, as
they're failing right now.
In addition I also needed to temporarily revert
0d2f06ae3a, which supposedly should fix
issues with Python 2 but aparently breaks Python 3 support and during
the beets tests we get a ModuleNotFoundError for the "_gi_gst" module.
However I didn't further investigate why this happens, as I'm time
constrained right now. But after disabling the pylint tests and the
revert of the mentioned gst-python commit, the beets tests succeed.
Signed-off-by: aszlig <aszlig@nix.build>
Cc: @jtojnar, @lopsided98 (for introducing the gst-python change)
Cc: @domenkozar, @pjones (other beets maintainers)
Since the switch to using python3Packages in commit
72934aa94e, the plugins no longer build
because they end up with a mix of Python 2 and Python 3 packages.
The reason for this is that the Beets package itself uses callPackage to
reference the plugins, however the overrides are not applied there and
thus the plugins end up getting pythonPackages from the top-level which
is Python 2 and beets with Python 3 dependencies.
Unfortunately this is not the only reason for the builds to fail,
because both plugins did not actually support Python 3.
For the copyartifacts plugin, the fix is rather easy because we only
need to advance to two more recent commits from upstream, which already
contain fixes for Python 3.
The alternatives plugin on the other hand is not maintained anymore, but
there is a fork at https://github.com/wisp3rwind/beets-alternatives
which has a bunch of fixes. In 2e4aded366
I already backported one of these fixes to the version from
https://github.com/geigerzaehler/beets-alternatives, but for Python 3
support it's a bit more complicated than just one little fix.
So instead of adding another series of patches which replicate the code
base of the fork and become a maintenance burden, I opted to directly
switch to the fork and remove the patch on our side.
Signed-off-by: aszlig <aszlig@nix.build>
Cc: @domenkozar, @pjones, @Profpatsch
The upstream release notes are a bit bigger, so I'm not including it
here. You can find it at:
https://github.com/beetbox/beets/releases/tag/v1.4.7
Originally I wanted to just fix the build, which is currently broken
because a few tests have failed, but the fix for the tests is already
included in the 1.4.7 upstream release[1], so I opted to update instead.
Other than running the tests included in beets (in addition to
building/running tests of the "alternatives" and "copyartifacts"
external plugins) I have made some small queries on my local music
collection, but haven't tested import or any write operation.
[1]: https://github.com/beetbox/beets/commit/8eb50fee33044dea008408423ee
Signed-off-by: aszlig <aszlig@nix.build>
Cc: @domenkozar, @pjones
In order to run the tests for the external plugins of beets, we need to
have beets itself as a dependency. So in order to do that, we now pass
beets without plugins and tests to the nativeBuildInputs of the plugins
so that we can run them.
As soon as the plugins are built they become part of the final beets,
which also has tests enabled, so disabling the tests for beets
derivation that is used for external plugin tests is a non-issue here
because they're going to be executed anyway.
Enabling tests for the alternatives plugin is pretty straightforward,
but in order to run tests for the copyartifacts plugin, we need to bump
the source code to the latest Git master.
The reason for this is that the version that was in use until now
required to have the beets source directory alongside of the
copyartifacts source code, but we already have beets available as a
normal dependency.
Updating copyartifacts to latest master largely consists of unit test
changes and a few Python 3 compatibility changes. However, one change
has the biggest stat, which is
sbarakat/beets-copyartifacts@1a0c281da0.
Fortunately, the last change is just moving the implementation to a
newer API from upstream beets and by the looks of the implementation it
seems to break support for moving files. However, reverting this commit
also reveals that moving files was already broken before, so it wouldn't
matter much whether we have this version bump or not.
Tested with the following command:
nix-build -E '(import ./. {}).beets.override {
enableAlternatives = true;
enableCopyArtifacts = true;
}'
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
Cc: @domenkozar, @pjones, @Profpatsch, @michalrus
