(Sorry for a repeated message; email error on my side)
-------------------- Start of forwarded message -------------------- From: Yoni Rabkin <[email protected]> To: Fran Burstall <[email protected]> Cc: Bruno Félix Rezende Ribeiro <[email protected]>, emms-help <[email protected]> Subject: Re: Why EMMS is not in GNU ELPA? Date: Sat, 11 Apr 2020 17:59:14 -0400 Fran Burstall <[email protected]> writes: > Dear All, > > My two cents worth: > > 1. emms has been on MELPA for years and I am not sure what the win is > to have it on ELPA instead or as well. > > 2. The MELPA package simply ignores the issue of emms-print-metadata > and does not provide the src for it. This has causes queries on > reddit and elsewhere over the years. This is exactly the type of feedback I was looking for. Thank you for this information. > 3. There is prior art for a MELPA package compiling extra programs > that it needs. A complete example is the pdf-tools package which > needs to compile epdfinfo to work. This works by firing a > compilation buffer pointing at a shell build script that (optionally) > handles OS dependencies. This would be do-able for > emms-print-metadata but would need someone who knew their way around > multiple distribution package managers (apt, pacman, etc). A less > automated solution would be to do what the emms tarball currently does > and assume the existence of a c++ compiler and taglib on the target > system but package emms-print-metadata.cpp and a makefile along with > some lisp to compile and install. > > 4. Maybe an alternative to emms-print-metadata would be more > attractive. It seems that there are a zillion wrappers to taglib out > there. One example is https://pypi.org/project/pytaglib/ which comes > with a tag reader pyprinttags which (a) works and (b) was easy to > install: pip install pytaglib (assuming that libtag is already present > on the system). All that would need to be done to use this in emms > would be to get emms-info-libtag to parse the output. I was thinking along the exact same lines. I'll have a look at these. Thanks again. > ---Fran > > > On Fri, 10 Apr 2020 at 19:47, Yoni Rabkin <[email protected]> wrote: > > Bruno Félix Rezende Ribeiro <[email protected]> writes: > > > Yoni Rabkin <[email protected]> writes: > > > >> I've personally never used ELPA and don't understand the point > of it. > > > > Why do you say that you “don't understand the point of it”? > > ...because I don't (I'm usure of what you are asking here > though.) > > However, I'll try to get Emms into ELPA if that is what people > want. I'm > maintaining Emms on behalf of GNU; not just for my own personal > benefit. > > > >> One issue would be to figure out how to ship the src/ > directory with > >> the non-elisp parts and how to get those compiled. > > > > How these work? I presume they are compiled and used as > sub-processes. > > Would not the new modules[1] support be more appropriate here? > Indeed, > > we’d have to figure out how those architecture-dependent parts > are > > supposed to get distributed. I think packages that use them > have a > > compilation script written in Lisp that is triggered on-demand > in the > > first use. > > > > > > Footnotes: > > [1] (info "(elisp) Writing Dynamic Modules") > > There are a few ways of doing this. > > Ideally, I would want to get rid of emms-print-metadata in favor > of > calling: > > * a library linked to emacs when it was compiled, or > dynamically > called by emacs > > * a command line tool that can be easily installed on an > endorsed > gnu/linux distribution > > The current situation of needing to compile a bespoke piece of > software > for taglib is suboptimal and confuses many people (based on > questions > I've received over the years). Moreover, "automating" the > compilation > won't work unless you also have a way of automating the > installation of > compilation tools onto the machine as well. > > It's still better than bongo's method of relying on filenames, > but that > isn't saying a whole lot. > > Perhaps the "modules" method is good, but depending on how new it > is, it > may leave behind everyone who wants to enjoy Emms but is stuck on > an > older emacs. I'll have to look into it. > > ...it seems like we have a worthy target for the 6.x release for > Emms. > > -- > "Cut your own wood and it will warm you twice" > > > > -- "Cut your own wood and it will warm you twice" -------------------- End of forwarded message -------------------- -- "Cut your own wood and it will warm you twice"
