emms-help
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Why EMMS is not in GNU ELPA?


From: Yoni Rabkin
Subject: Re: Why EMMS is not in GNU ELPA?
Date: Fri, 24 Apr 2020 16:14:27 -0400
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.91 (gnu/linux)

Fran Burstall <address@hidden> writes:

> 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've also written to emacs-devel asking them if they have any input on
how we can streamline access to taglib for Emms.

Unless the people from emacs-devel come up with some brilliant idea we
should try instead, we should try pytaglib on people after releasing 5.4
(first of May).

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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]