[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Yoni Rabkin] Re: Why EMMS is not in GNU ELPA?
From: |
Yoni Rabkin |
Subject: |
[Yoni Rabkin] Re: Why EMMS is not in GNU ELPA? |
Date: |
Sat, 11 Apr 2020 22:06:08 -0400 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/27.0.90 (gnu/linux) |
(Sorry for a repeated message; email error on my side)
-------------------- Start of forwarded message --------------------
From: Yoni Rabkin <address@hidden>
To: Fran Burstall <address@hidden>
Cc: Bruno Félix Rezende Ribeiro <address@hidden>,
emms-help
<address@hidden>
Subject: Re: Why EMMS is not in GNU ELPA?
Date: Sat, 11 Apr 2020 17:59:14 -0400
Fran Burstall <address@hidden> 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 <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"
>
>
>
>
--
"Cut your own wood and it will warm you twice"
-------------------- End of forwarded message --------------------
--
"Cut your own wood and it will warm you twice"
[Prev in Thread] |
Current Thread |
[Next in Thread] |
- [Yoni Rabkin] Re: Why EMMS is not in GNU ELPA?,
Yoni Rabkin <=