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. 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. ---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" > >
