[Abcde-users] Running abcde on recent Mac OS X versions

Gabriel Rosenkoetter gr at eclipsed.net
Fri Aug 19 17:30:18 BST 2016


For a variety of reasons, I'm in the process of reripping my CD collection, which means I just came back to abcde for the first time in… 14 years? Back then, I'd just installed it out of FreeBSD's ports collection, and I didn't really care about applying album art to the output mp3s (maybe id3 tags of the time didn't even support that) so everything Just Worked. Such was not the case this past week on Mac OS X (but it does absolutely work).

Up here where there's a good chance that people will see them, I've got some questions (some of which depend upon the stuff below for comprehension):

1. Is anybody else on this list using abcde on Mac OS X? (Especially, if you fulfilled the various external tool requirements via Homebrew, rudix, or something else, it'd be neat to know how that went. I used MacPorts, mostly.)

2. It seems like the WebService::MusicBrainz Perl module that abcde-musicbrainz-tool depends upon has been kind of abandoned for something like 6 years, and I'm wondering whether it wouldn't be a good idea to rework abcde-musicbrainz-tool to use a different module to speak to MusicBrainz (plausibly on a newer version of their API). To be clear, I do actually know Perl and am familiar with REST APIs, so I'm not suggesting somebody else go do that, but volunteering that I could, but maybe somebody else has already started on this?

3. Andrew, I found your recent (I think, since they're talking about 2.7.2) write-ups of what to put in ~/.abcde.conf extremely helpful. I do, however, have some Mac OS X-specific suggestions for http://www.andrews-corner.org/getalbumart.html (short version: on Mac OS X, we can skip making both X11 and ImageMagick behave, because we can use the native open(1) utility to kick a retrieved cover art image into the user's preferred native image viewer, which by default is Preview.app).


A little more background on how I got to those questions:

These days, all the computers that exist physically in my home run Mac OS X (10.11, "El Capitan"), where satisfying abode's requirements is a little more complicated. I did this (twice, and took better notes the second time) with a combination of MacPorts and manually installing components (WebService::MusicBrainz via CPAN and glyr manually, satisfying its dependencies via MacPorts). I'm not sure whether that would go more or less smoothly with Homebrew instead, but it should be just as doable there. If anybody'd benefit from my notes, I'm happy to clean them up and post them here (or on a website, which may be more practical).

Specifically wrt WebService::MusicBrainz, there are a couple of recent pulls of patches provided by others at https://github.com/bfaist/webservice-musicbrainz, including two that explicitly fix bugs reported via CPAN, but those patches haven't yet made it into the CPAN version (because, I think, the original author would have to do that, unless somebody forks WS::MB and adds it to CPAN under their ID). Worse, even with the patches present on the github side, the package reliably fails the same tests every time (so I don't think this is the periodic failures that the author, Bob Faist, notes in his README may occur during times of heavy load on the MusicBrainz side; I think there may have been changes to the API on the MB side that break what WS::MB is requesting). The good news is that doing a force install of the Perl module results in something that seems to work for abcde's use (the failed tests are all around entity X being related to entity Y, at least at a glance, and I don't think abcde ever has cause to run those queries), but I'm wondering whether it might be a good idea to either switch to a different module for the MB queries (or plausibly submit some patches to Bob and help get the CPAN version updated; I did also drop him an email, yesterday US Eastern time, asking politely whether he was still trying to maintain the thing or had just moved on to other things).

I also plan to go see if I can get some things updated in MacPorts (for example, they're still shipping abcde 2.7, which is explicitly broken on Mac OS X because of https://abcde.einval.com/bugzilla/show_bug.cgi?id=22, which someone over there noticed months ago--https://trac.macports.org/ticket/49799--but nobody ever actually pulled the trigger on just updating to 2.7.2) to try to make it so that doing a `port install abcde` on Mac OS X Just Works. There are some other silly pieces in MacPorts (for example, there is a completely functional eyeD3 package there--named py-eyeD3-2.7--but it installs the executable as "eyeD3-x.x" where x.x is the version of Python you have installed, because it does that with anything that depends on a specific Python version… and you can do port `select --set python python27` to say "I want to use this version", but that only creates a python sym link to python2.7: it doesn't do the same for other packages that depend on python version; yes, abcde can deal with this by setting EYED3 to eyeD3-2.7 in an abcde.conf, but that seems dumb to me). I'm warming up to wading into providing those MacPorts updates, but I think that's a bigger hunk of raw meat to chew than the WebService::MusicBrainz thing (and getting WS::MB fixed or replaced is a pre-req for creating a MacPorts package for it), so I'm starting here. :^>

If anybody else has gone through the motions of satisfying abode's dependencies through some other Mac OS X Unix-like software packaging utility (that's at least Homebrew and rudix… there may well be others that I don't know about), I'd like to compare notes. It'd be nice for all of those to have an abcde package that Just Worked, including all the bits and pieces that

--
Gabriel Rosenkoetter
gr at eclipsed.net

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 236 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.einval.com/pipermail/abcde-users/attachments/20160819/4079cb8d/attachment.sig>


More information about the Abcde-users mailing list