Re: Why EMMS is not in GNU ELPA?

[Fran Burstall]

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 <address@hidden> wrote:

Bruno Félix Rezende Ribeiro <address@hidden> writes:

> Yoni Rabkin <address@hidden> 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"