[Yoni Rabkin] Re: Why EMMS is not in GNU ELPA?

classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view

[Yoni Rabkin] Re: Why EMMS is not in GNU ELPA?

Yoni Rabkin-2

(Sorry for a repeated message; email error on my side)

-------------------- Start of forwarded message --------------------
From: Yoni Rabkin <[hidden email]>
To: Fran Burstall <[hidden email]>
Cc: Bruno Félix Rezende Ribeiro <[hidden email]>,
 <[hidden email]>
Subject: Re: Why EMMS is not in GNU ELPA?
Date: Sat, 11 Apr 2020 17:59:14 -0400

Fran Burstall <[hidden email]> 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 <[hidden email]> wrote:
>     Bruno Félix Rezende Ribeiro <[hidden email]> writes:
>     > Yoni Rabkin <[hidden email]> 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"