Why EMMS is not in GNU ELPA?

classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

Why EMMS is not in GNU ELPA?

Bruno Félix Rezende Ribeiro-2
Hello fellow EMMS users and developers,

Being EMMS an official GNU package, why isn’t it in GNU ELPA?[1]

I found a discussion on emacs-devel[2] (dating from 2013) regarding an
initiative to include it there, but perhaps it was not pursued further?


Footnotes:
[1]  https://elpa.gnu.org/packages/

[2]  https://lists.gnu.org/archive/html/emacs-devel/2013-06/msg01210.html

--
Bruno Félix Rezende Ribeiro (oitofelix) [0x28D618AF]
<http://oitofelix.freeshell.org/>

signature.asc (463 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Why EMMS is not in GNU ELPA?

Yoni Rabkin-2
Bruno Félix Rezende Ribeiro <[hidden email]> writes:

> Hello fellow EMMS users and developers,
>
> Being EMMS an official GNU package, why isn’t it in GNU ELPA?[1]
>
> I found a discussion on emacs-devel[2] (dating from 2013) regarding an
> initiative to include it there, but perhaps it was not pursued further?
>
>
> Footnotes:
> [1]  https://elpa.gnu.org/packages/
>
> [2]
> https://lists.gnu.org/archive/html/emacs-devel/2013-06/msg01210.html

There is no reason in principle why Emms could not be in ELPA. I've
personally never used ELPA and don't understand the point of it. But if
people want Emms in ELPA we'll do it.

One issue would be to figure out how to ship the src/ directory with the
non-elisp parts and how to get those compiled. Does anyone, preferably
someone who uses and/or knows about ELPA, want to tackle this issue and
report back on how other packages do it, and how Emms might do the same?

P.S. In the meantime, I've been asked to make an elisp package I wrote
(rt-liberation) a GNU project and add that to ELPA. When I finish that
process I'll know a bit more about what's involved.

--
   "Cut your own wood and it will warm you twice"

Reply | Threaded
Open this post in threaded view
|

Re: Why EMMS is not in GNU ELPA?

Bruno Félix Rezende Ribeiro-2
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”?


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

--
Bruno Félix Rezende Ribeiro (oitofelix) [0x28D618AF]
<http://oitofelix.freeshell.org/>

signature.asc (497 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Why EMMS is not in GNU ELPA?

Yoni Rabkin-2
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"

Reply | Threaded
Open this post in threaded view
|

Re: Why EMMS is not in GNU ELPA?

Bruno Félix Rezende Ribeiro-2
Yoni Rabkin <[hidden email]> writes:

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

Sorry, if I was not clear enough.  I was wondering if you have a
rationale backing up your stance that releasing packages on GNU ELPA
does not make sense.

I mean, do you see a point in releasing it on MELPA, or any other ELPA
for that matter?  If not, why not?  Or that’s specific to GNU ELPA?  If
that’s so, why so?

--
Bruno Félix Rezende Ribeiro (oitofelix) [0x28D618AF]
<http://oitofelix.freeshell.org/>

signature.asc (497 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Why EMMS is not in GNU ELPA?

Yoni Rabkin-2
Bruno Félix Rezende Ribeiro <[hidden email]> writes:

> Yoni Rabkin <[hidden email]> writes:
>
>> 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.)
>
> Sorry, if I was not clear enough.  I was wondering if you have a
> rationale backing up your stance that releasing packages on GNU ELPA
> does not make sense.
>
> I mean, do you see a point in releasing it on MELPA, or any other ELPA
> for that matter?  If not, why not?  Or that’s specific to GNU ELPA?  If
> that’s so, why so?

Ah, I understand the confusion now. Thank you for clearing that up.

My personal opinion is that ELPA, MELPA, (and tomorrow probably XELPA,
FELPA, NELPA, GELPA, etc.) are all like M-x customize: ugly, baroque
monsters that take up a huge amount of effort and complexity to do a
very simple task... poorly.

(Indeed, this is a disease that the entire free software world suffers
from: rpm, entropy, flatpak, pacman, deb, apt, slackpkg, yum, dnf, abs,
snappy, 0install, portage, etc. and etc. and so on and so forth. The
100th time you reinvent the wheel you need to start questioning why the
previous 99 times didn't work...)

What is important in the above statement is not if I have a point or if
I'm right about software packaging and distribution, but that as a
result of my preference I remain largely ignorant of how those systems
work, which puts me at a disadvantage when we need to add Emms to those
systems.

This is why I asked that people who are familiar with ELPA and the such,
and are fans of that kind of thing, to research how to add Emms to them
correctly.

--
   "Cut your own wood and it will warm you twice"

Reply | Threaded
Open this post in threaded view
|

Re: Why EMMS is not in GNU ELPA?

Fran Burstall-3
In reply to this post by Yoni Rabkin-2
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 <[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"

Reply | Threaded
Open this post in threaded view
|

Re: Why EMMS is not in GNU ELPA?

Yoni Rabkin-2
Fran Burstall <[hidden email]> 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 <[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"