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
* ultrastardx-beta: init at 1.3.5
* libbass, libbass_fx: init at 24
* ultrastar-creator: init at 2017-04-12
* buildSupport/plugins.nix: add diffPlugins
Helper function to compare expected plugin lists to the found plugins.
* ultrastar-manager: init at 2017-05-24
The plugins are built in their own derivations, speeding up (re-)compilation.
The `diffPlugins` function from `beets` is reused to test for changes in the
plugin list on updates.
* beets: switch to diffPlugins
The function is basically just extracted for better reusability.
So this was suggested as [long ago as October, 2015](https://github.com/NixOS/nixpkgs/issues/10376#issuecomment-147734898).
Despite being fairly ignorant of the nix Python support, I decided
that I really wanted this; this change brings in what I believe are
the necessary components---I have, at least, successfully run `beet
replaygain` and `beet bpd`---but it may not do it in the best way; I'm
happy to consider input on that front.
I can at least state that all three changes are necessary---leave any
one of them out and gstreamer support doesn't work.
This largely reverts commit 599312739e.
The main reason is that it breaks the plugins, because the mentioned
commit didn't change the attributes for the plugins as well.
But instead of just fixing the attributes when we import the plugin
packages, let's just override pythonPackages in all-packages.nix.
Right now, Beets is in transition to Python 3, so we don't need to wait
that long until we can remove the dependency on Python 2:
https://github.com/beetbox/beets/releases/tag/v1.4.1
Once Python 3 support is no longer beta, we can just change this by
changing one line only instead of several.
Tested this by building beets with both external plugins.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
Cc: @FRidh
Full upstream release announcement:
https://github.com/beetbox/beets/releases/tag/v1.4.1
I had to rebase the keyfinder-default-bin.patch in order to apply with
the new release.
Other than that I didn't test whether beets works on my machine, as I
have a more or less temporary setup at the moment.
However, since the bump of mutagen to version 1.34 in commit
555928c228, the mediafile tests fail and
thus this commit unbreaks beets.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
The top-level attribute has been removed in commit
771ed59b48.
This has been partially resolved in commit
18bdd44729.
The latter change however only addressed the main derivations but missed
out on the plugins. This is now done by just passing pythonPackages down
the chain.
Tested by only evaluating the expression, not building.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
Cc: @domenkozar, @pjones, @profpatsch
The echonest plugin was removed in 3.18 because the API it used is
shutting down. You might want to try the acousticbrainz instead.
Update pluginsWithoutDeps as needed to keep preCheck working.
The default convert configuration invokes ffmpeg, so this patches in the
right storepath. Since it patches the shlex split, even user config will
use the correct path. kudos @aszlig.
The reason why the completion tests didn't pass was because we had it
already disabled in 2acc258dff.
Meanwhile, beetbox/beets@a07cb83 has moved the file from
test/test_completion.sh to test/rsrc/test_completion.sh.
So this has silently re-enabled the completion tests, which we need to
investigate on our side why they failed in the first place.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
It's not included in upstream beets but are linked in the documentation
under "Other plugins", see:
http://beets.readthedocs.org/en/v1.3.15/plugins/index.html#other-plugins
I found this one particularly useful for syncing files to varios media
players that refuse to read my FLAC files properly.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
After trying with a dozen files, it seems the bs1770gain backend is much
more reliable than the audiotools backend and especially does a better
job (well, compared to audiotools which either does doing nothing at all
or throws an exception) when used on alboms that contain different
sample rates/sizes.
Additionally, we already had a few issues regarding the audiotools
backend, even to the extent that @sampsyco almost wanted to drop it
upstream (see sampsyco/beets#1342).
Also related issues are #10376 and sampsyo/beets#1592.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
I have to admit that I did very poor testing in d7307d8 and didn't
notice that the "badfiles" plugin relies on mp3val (thanks to @devhell
for packaging in 6e1ef13) and flac to be actually useful.
We now patch in the store locations of these binaries and make
"badfiles" an optional dependency (though enabled by default).
Now, I have tested "beet bad" on my whole music collection and it worked
fine (well, it has found errors... but that's what it is for).
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
Introduces a new plugin called "badfiles", which helps to scan for
corruption within the music collection. I've added this to
pluginsWithoutDeps and sorted the list.
Full upstream changelog can be found here:
https://github.com/sampsyo/beets/releases/tag/v1.3.15
This fixes#10376 via sampsyo/beets@225ba28.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
We're passing glibcLocales to the tests directly, so we don't pollute
the builder's environment anyway, so no reason to override anything
there.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
I know, I know, this is me being ultra-nazi about those things, but
beets is about OCDing your music collection, so why not apply this to
the Nix expressions as well?
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
We can now finally drop the mediafile and test fix patches, because they
were already coming from the upstream repository and are now included in
the release.
Also, this release brings two new plugins:
* permissions: Fix permissions on music files as they are imported.
* plexupdate: Notify a Plex server when the database changes.
The echonest_tempo plugin has finally been removed and so we can drop it
entirely. No plugin as of now tries to do interactive prompts on "beet
config" anymore, so we can test *all* plugins and without providing
dummy options.
The full list of changes can be found here:
https://github.com/sampsyo/beets/releases/tag/v1.3.10
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
See, that's why I hate the gregorian calendar and new years eve: People
tend to celebrate things that are absolutely irrelevant, like this
comment.
The test however assumed that either beets or its test suite would never
survive 2015, so this test should assure it won't survive in >= 2015 :-)
Anyway, the patch is from upstream master, so we can drop it once 1.3.10
is released.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
Beets tries to load oll activated plugins on "beet config -e" (however
only on the second run, thus the dummy), so we just pass all activated
plugins into a generated config file and bail out on any errors.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
The reason for doing this is in order to not forget about possible
dependencies in new upstream releases, so if upstream is introducing a
new plugin where we're lacking dependencies, the build will fail on our
side and we can check whether we'll need those.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
