Adding Emms to ELPA (take 2), and a technical question

Adding Emms to ELPA (take 2), and a technical question

[Yoni Rabkin]

Hello all, I'm the current Emms (https://www.gnu.org/software/emms/)
maintainer.

Back in October of 2014 I started the process of adding Emms to ELPA;
that exposed a lot of work that needed to be done. I've been receiving
multiple requests as of late to add Emms to ELPA, so I'm following it
up.

The main issue back then was that Emms was a copyright mess. Stefan
Monnier helped me figuring out who to contact and I've fixed that since
(took a while). To the best of my knowledge, everyone who has code in
Emms has an assignment on file. Emms has an AUTHORS file which is kept
up-to-date. Everyone there should also appear in the FSF records.

Stefan also said that ELPA packages need to have their .el files at the
top-level. However, Emms has its files in a lisp/ directory. This is
still the case, and I would like to keep it that way because Emms has a
lot of files and a lisp/ directory keeps things tidy. Is this still a
requirement for ELPA? I hope not.

Emms also comes with a small piece of code that needs to be compiled in
order to use taglib (https://taglib.org/). The code is in a src/
directory in the Emms distribution. I understand that there is no way to
get ELPA to compile something as a part of the installation. We can
forgo any compilation at the ELPA installation stage as long as people
get to read the excellent Emms manual which explains how (and why) to
compile that bit of code. Would any of this be a problem for adding Emms
to ELPA? In case it matters, people (not me) have been making Emms
available via MELPA for many years now. They simply ignore the
compilation step, and allow the user to either read the manual or ask
online to figure it out.

Which leads me to my technical question:

We (the Emms developers) are desperately looking for a better way to
give Emms access to taglib other than compiling glue code like we do
now. We really don't want to ship C, or C++, or Perl, or anything except
elisp with Emms. One option we are currently exploring is to ask the
user to install an existing package such as pytaglib (a GPLv3 python
wrapper around taglib). Is there any more elegant way to get access to
taglib through Emacs that anyone can suggest?

Thank you, and have a great weekend y'all.


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

Re: Adding Emms to ELPA (take 2), and a technical question

[Stefan Monnier]

> The main issue back then was that Emms was a copyright mess. Stefan
> Monnier helped me figuring out who to contact and I've fixed that since
> (took a while). To the best of my knowledge, everyone who has code in
> Emms has an assignment on file. Emms has an AUTHORS file which is kept
> up-to-date. Everyone there should also appear in the FSF records.

Great news, thank you!

> Stefan also said that ELPA packages need to have their .el files at the
> top-level.  However, Emms has its files in a lisp/ directory. This is
> still the case, and I would like to keep it that way because Emms has a
> lot of files and a lisp/ directory keeps things tidy. Is this still a
> requirement for ELPA?

Yes, and you even wrote it right: it's a property of ELPA (and not
specific to GNU ELPA), so it affects MELPA just as well.  This comes
from the fact that only top-level files are scanned for `;;;###autoload`
cookies when the package is installed.

You can work around this problem with extra work, tho: build your own
autoloads file for the files in `lisp/*.el` and distribute it as if it
were a "source" file.

The Hyperbole package does that for its `kotl` subdirectory:
they "manually" builds&updates a `kotl/kotl-autoloads.el` file (the rule
to update it is in a Makefile), and then in `hyperbole.el` they have:

    ;;;###autoload (load "kotl/kotl-autoloads" nil 'nowarn)

> Emms also comes with a small piece of code that needs to be compiled in
> order to use taglib (https://taglib.org/). The code is in a src/
> directory in the Emms distribution. I understand that there is no way to
> get ELPA to compile something as a part of the installation.

Yes, there is.  You can put something like:

    (eval-when-compile (call-process "make"))

in your main file, for example.

> We can forgo any compilation at the ELPA installation stage as long as
> people get to read the excellent Emms manual which explains how (and
> why) to compile that bit of code.  Would any of this be a problem for
> adding Emms to ELPA?

These will require extra work on your part, but other than that, no,
they don't impact your ability to add the package to GNU ELPA.

> We (the Emms developers) are desperately looking for a better way to
> give Emms access to taglib other than compiling glue code like we do
> now. We really don't want to ship C, or C++, or Perl, or anything except
> elisp with Emms. One option we are currently exploring is to ask the
> user to install an existing package such as pytaglib (a GPLv3 python
> wrapper around taglib). Is there any more elegant way to get access to
> taglib through Emacs that anyone can suggest?

I'm afraid I don't have a better solution to offer.


        Stefan

Re: Adding Emms to ELPA (take 2), and a technical question

[Yoni Rabkin]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> The main issue back then was that Emms was a copyright mess. Stefan
>> Monnier helped me figuring out who to contact and I've fixed that since
>> (took a while). To the best of my knowledge, everyone who has code in
>> Emms has an assignment on file. Emms has an AUTHORS file which is kept
>> up-to-date. Everyone there should also appear in the FSF records.
>
> Great news, thank you!
>
>> Stefan also said that ELPA packages need to have their .el files at the
>> top-level.  However, Emms has its files in a lisp/ directory. This is
>> still the case, and I would like to keep it that way because Emms has a
>> lot of files and a lisp/ directory keeps things tidy. Is this still a
>> requirement for ELPA?
>
> Yes, and you even wrote it right: it's a property of ELPA (and not
> specific to GNU ELPA), so it affects MELPA just as well.  This comes
> from the fact that only top-level files are scanned for `;;;###autoload`
> cookies when the package is installed.
>
> You can work around this problem with extra work, tho: build your own
> autoloads file for the files in `lisp/*.el` and distribute it as if it
> were a "source" file.
>
> The Hyperbole package does that for its `kotl` subdirectory:
> they "manually" builds&updates a `kotl/kotl-autoloads.el` file (the rule
> to update it is in a Makefile), and then in `hyperbole.el` they have:
>
>     ;;;###autoload (load "kotl/kotl-autoloads" nil 'nowarn)

I'll look at hyperbole as a reference.

>> Emms also comes with a small piece of code that needs to be compiled in
>> order to use taglib (https://taglib.org/). The code is in a src/
>> directory in the Emms distribution. I understand that there is no way to
>> get ELPA to compile something as a part of the installation.
>
> Yes, there is.  You can put something like:
>
>     (eval-when-compile (call-process "make"))
>
> in your main file, for example.

We would need to make sure that there are compilation tools ready on the
machine first.

>> We can forgo any compilation at the ELPA installation stage as long as
>> people get to read the excellent Emms manual which explains how (and
>> why) to compile that bit of code.  Would any of this be a problem for
>> adding Emms to ELPA?
>
> These will require extra work on your part, but other than that, no,
> they don't impact your ability to add the package to GNU ELPA.
>
>> We (the Emms developers) are desperately looking for a better way to
>> give Emms access to taglib other than compiling glue code like we do
>> now. We really don't want to ship C, or C++, or Perl, or anything except
>> elisp with Emms. One option we are currently exploring is to ask the
>> user to install an existing package such as pytaglib (a GPLv3 python
>> wrapper around taglib). Is there any more elegant way to get access to
>> taglib through Emacs that anyone can suggest?
>
> I'm afraid I don't have a better solution to offer.

We'll keep on looking.

Thank you. I'll post again if we end up with emacs-devel-ish questions,
or when we are all done.

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

Re: Adding Emms to ELPA (take 2), and a technical question

[Robert Pluim]

>>>>> On Tue, 28 Apr 2020 09:28:56 -0400, Yoni Rabkin <yoni@rabkins.net> said:
    >> Yes, there is.  You can put something like:
    >> 
    >> (eval-when-compile (call-process "make"))
    >> 
    >> in your main file, for example.

    Yoni> We would need to make sure that there are compilation tools ready on the
    Yoni> machine first.

Iʼd take a look at 'pdf-tools', it both compiles C-code and installs
necessary packages using 'apt-get' and similar.

Robert

Re: Adding Emms to ELPA (take 2), and a technical question

[Yoni Rabkin]

Robert Pluim <rpluim@gmail.com> writes:

>>>>>> On Tue, 28 Apr 2020 09:28:56 -0400, Yoni Rabkin <yoni@rabkins.net> said:
>     >> Yes, there is.  You can put something like:
>     >> 
>     >> (eval-when-compile (call-process "make"))
>     >> 
>     >> in your main file, for example.
>
>     Yoni> We would need to make sure that there are compilation tools ready on the
>     Yoni> machine first.
>
> Iʼd take a look at 'pdf-tools', it both compiles C-code and installs
> necessary packages using 'apt-get' and similar.

Thank you, that is good to know. I'll make sure to do that.

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

Re: Adding Emms to ELPA (take 2), and a technical question

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > Iʼd take a look at 'pdf-tools', it both compiles C-code and installs
  > necessary packages using 'apt-get' and similar.

That is an undesirable practice: it turns package installation into
something users won't keep track of.

(Secondary practical issue: to succeed in running apt-get it would
have to run as root, I think.)



-- 
Dr Richard Stallman
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: Adding Emms to ELPA (take 2), and a technical question

[Robert Pluim]

>>>>> On Tue, 28 Apr 2020 23:22:55 -0400, Richard Stallman <rms@gnu.org> said:

    Richard> [[[ To any NSA and FBI agents reading my email: please consider    ]]]
    Richard> [[[ whether defending the US Constitution against all enemies,     ]]]
    Richard> [[[ foreign or domestic, requires you to follow Snowden's example. ]]]

    >> Iʼd take a look at 'pdf-tools', it both compiles C-code and installs
    >> necessary packages using 'apt-get' and similar.

    Richard> That is an undesirable practice: it turns package installation into
    Richard> something users won't keep track of.

If you want to use pdf-tools, and decide not to let it install the
required packages for you, you have to install them on its behalf. I
donʼt see the practical difference. The documentation of pdf-tools is
very clear about how to do the installation by hand.

    Richard> (Secondary practical issue: to succeed in running apt-get it would
    Richard> have to run as root, I think.)

It uses 'sudo', and is very clear about that too. Of course if youʼre
installing by hand you can install packages as non-root and play games
with PKG_CONFIG_PATH to get pdf-tools to find them.

(this is where someone points out a GNU/Linux package management
system where *everything* is installed as non-root :-) )

Robert

Re: Adding Emms to ELPA (take 2), and a technical question

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > If you want to use pdf-tools, and decide not to let it install the
  > required packages for you, you have to install them on its behalf.

That way of doing things is fine.  Having one package automatically
install another package is asking for trouble.

  > It uses 'sudo', and is very clear about that too. Of course if youʼre
  > installing by hand you can install packages as non-root and play games
  > with PKG_CONFIG_PATH to get pdf-tools to find them.

This seems like really asking for it.  I don't think packages should
behave this way.


-- 
Dr Richard Stallman
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: Adding Emms to ELPA (take 2), and a technical question

[Yoni Rabkin]

Richard Stallman <rms@gnu.org> writes:

> [[[ To any NSA and FBI agents reading my email: please consider    ]]]
> [[[ whether defending the US Constitution against all enemies,     ]]]
> [[[ foreign or domestic, requires you to follow Snowden's example. ]]]
>
>   > Iʼd take a look at 'pdf-tools', it both compiles C-code and installs
>   > necessary packages using 'apt-get' and similar.
>
> That is an undesirable practice: it turns package installation into
> something users won't keep track of.
>
> (Secondary practical issue: to succeed in running apt-get it would
> have to run as root, I think.)

I won't be able to speak to what pdf-tools is doing until I have a close
look. I may write back in once I've had a look at pdf-tools and
understand the process. It may be easier to decide once we have that
information.

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

Re: Adding Emms to ELPA (take 2), and a technical question

[Yoni Rabkin]

Richard Stallman <rms@gnu.org> writes:

> [[[ To any NSA and FBI agents reading my email: please consider    ]]]
> [[[ whether defending the US Constitution against all enemies,     ]]]
> [[[ foreign or domestic, requires you to follow Snowden's example. ]]]
>
>   > Iʼd take a look at 'pdf-tools', it both compiles C-code and installs
>   > necessary packages using 'apt-get' and similar.
>
> That is an undesirable practice: it turns package installation into
> something users won't keep track of.
>
> (Secondary practical issue: to succeed in running apt-get it would
> have to run as root, I think.)

I've had a look at pdf-tools and arrived at the conclusion that we won't
be copying much from what pdf-tools does into Emms; the two project are
too different, and pdf-tools does a few of other things I don't agree
with. Any copying will probably be limited to the some stuff in the
Makefile of pdf-tools that helps it prepare to be distributed with ELPA.

That's the short of it. No need to read more if that is all you needed
to know. Below the line is the longer version for anyone curious, or
with too much time on their hands.

----------------------------------------------------------------------

pdf-tools does a lot more compilation than Emms. pdf-tools comes with
over 13,000 lines of C/C++, while Emms has under 200 lines of C/C++.

pdf-tools requires the compilation step in order to function at all. But
Emms works fine without compiling anything, and only uses the
compilation step to provide a binary which enhances functionality.

Where Emms and pdf-tools are alike is that they both require build-tools
to be present on the machine, and the compilation step is in essence the
same. This is why I'll see if the pdf-tools Makefile has anything
valuable for Emms and use that.

Outside of compilation, I find it annoying that pdf-tools doesn't come
with a proper manual. I needed to go and look up to figure out how to
read the org file that came with pdf-tools. It isn't that much text, and
the annoying folding that org does for what amounts to a simple README
file is gratuitous at best.

pdf-tools also uses its a package/distribution manager called cask, and
also something called appveyor which I looked up on Wikipedia and found
that "AppVeyor is a hosted, distributed continuous integration service",
but that left me none the wiser as to why an AppVeyor file/s come with
pdf-tools or what I am supposed to do with them. None of those make
sense for such a small project, so I'm assuming that those are simply
the tools the author/s of pdf-tools are used to working with, so that is
what they used.


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

Re: Adding Emms to ELPA (take 2), and a technical question

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

Lots of packages require building and that uses tools.
Emacs, for instance, needs various tools to build it,
including a C compiler.  Nothing wrong or unusual there.

What alarms me about pdf-tools is that it tries to install those tools
itself rather than leaving the user in control of that step.

-- 
Dr Richard Stallman
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: Adding Emms to ELPA (take 2), and a technical question

[Joost Kremers]

On Fri, May 01 2020, Richard Stallman wrote:
> [[[ To any NSA and FBI agents reading my email: please consider 
> ]]]
> [[[ whether defending the US Constitution against all enemies, 
> ]]]
> [[[ foreign or domestic, requires you to follow Snowden's 
> example. ]]]
>
> Lots of packages require building and that uses tools.
> Emacs, for instance, needs various tools to build it,
> including a C compiler.  Nothing wrong or unusual there.
>
> What alarms me about pdf-tools is that it tries to install those 
> tools
> itself rather than leaving the user in control of that step.

Mind you, pdf-tools does ask the user for permission first and it 
pops up a buffer where you can follow what is happening.

Honestly, as a user of pdf-tools, I'm glad this happen 
automatically if I choose to. Saves me from opening a shell and 
copy&pasting a bunch of commands.

-- 
Joost Kremers
Life has its moments

Re: Adding Emms to ELPA (take 2), and a technical question

[Arthur Miller]

Joost Kremers <joostkremers@fastmail.fm> writes:

> On Fri, May 01 2020, Richard Stallman wrote:
>> [[[ To any NSA and FBI agents reading my email: please consider ]]]
>> [[[ whether defending the US Constitution against all enemies, ]]]
>> [[[ foreign or domestic, requires you to follow Snowden's example. ]]]
>>
>> Lots of packages require building and that uses tools.
>> Emacs, for instance, needs various tools to build it,
>> including a C compiler.  Nothing wrong or unusual there.
>>
>> What alarms me about pdf-tools is that it tries to install those tools
>> itself rather than leaving the user in control of that step.
>
> Mind you, pdf-tools does ask the user for permission first and it pops up a
> buffer where you can follow what is happening.
>
> Honestly, as a user of pdf-tools, I'm glad this happen automatically if I choose
> to. Saves me from opening a shell and copy&pasting a bunch of commands.

How would you do it? Get Emacs to install and compile pdf tools from the
source, or just to call the package manager from the distribution/OS of
choice, which I sure are as many as users here.

I am defenetly more happy installing applications through package
manager from my distribution then through Emacs. Mostly because of
updates and dependencies with other applications. Will Emacs also track
when those tools are updated, bugs fixed etc?

Unless you would to turn Emacs into OS package manager a lá pacman, rpm,
etc, which I wouldn't mind by the way, but I don't think Emacs is there.

Also pdf-tools are used by other applications in system so it is
easy to get them in any distro, inclusive proprietary OS:s(Win,
Mac). Why shoujld pdf-tools be different then any other tool we use in
Emacs (binutils, compilers, debuggers, grep, ag, you-name-it)?

Re: Adding Emms to ELPA (take 2), and a technical question

[Joost Kremers]

On Fri, May 01 2020, Arthur Miller wrote:
> Joost Kremers <joostkremers@fastmail.fm> writes:
>> Honestly, as a user of pdf-tools, I'm glad this happen 
>> automatically if I choose to. Saves me from opening a shell and 
>> copy&pasting a bunch of commands.
>
> How would you do it? Get Emacs to install and compile pdf tools 
> from the source, or just to call the package manager from the 
> distribution/OS of choice, which I sure are as many as users 
> here.
>
> I am defenetly more happy installing applications through 
> package manager from my distribution then through Emacs. Mostly 
> because of updates and dependencies with other applications. 
> Will Emacs also track when those tools are updated, bugs fixed 
> etc?
>
> Unless you would to turn Emacs into OS package manager a lá 
> pacman, rpm,
> etc, which I wouldn't mind by the way, but I don't think Emacs 
> is there.
>
> Also pdf-tools are used by other applications in system so it is
> easy to get them in any distro, inclusive proprietary OS:s(Win,
> Mac). Why shoujld pdf-tools be different then any other tool we 
> use in
> Emacs (binutils, compilers, debuggers, grep, ag, you-name-it)?

I'm not quite sure I follow. We're talking about the Emacs package 
pdf-tools, which isn't used by other applications, because, well, 
it's an Emacs package. :-) The pdf-tools package uses a C program 
called epdfinfo to actually read the pdf and feed Emacs all the 
info it needs to display the pdf file. Epdfinfo is part of the 
pdf-tools package and needs to be compiled before you can use the 
package in Emacs.

Epdfinfo uses Poppler and in order for it to be built, a number of 
development requirements need to be installed. pdf-tools will try 
to install these through the system package manager, but this, 
too, can be done manually if you prefer.

So Emacs is not being made into a package manager for .deb or .rpm 
files, the only thing that needs to be compiled is a C program 
that comes with the package.

-- 
Joost Kremers
Life has its moments

Re: Adding Emms to ELPA (take 2), and a technical question

[Arthur Miller]

Joost Kremers <joostkremers@fastmail.fm> writes:

> On Fri, May 01 2020, Arthur Miller wrote:
>> Joost Kremers <joostkremers@fastmail.fm> writes:
>>> Honestly, as a user of pdf-tools, I'm glad this happen automatically if I
>>> choose to. Saves me from opening a shell and copy&pasting a bunch of
>>> commands.
>>
>> How would you do it? Get Emacs to install and compile pdf tools from the
>> source, or just to call the package manager from the distribution/OS of
>> choice, which I sure are as many as users here.
>>
>> I am defenetly more happy installing applications through package manager from
>> my distribution then through Emacs. Mostly because of updates and dependencies
>> with other applications. Will Emacs also track when those tools are updated,
>> bugs fixed etc?
>>
>> Unless you would to turn Emacs into OS package manager a lá pacman, rpm,
>> etc, which I wouldn't mind by the way, but I don't think Emacs is there.
>>
>> Also pdf-tools are used by other applications in system so it is
>> easy to get them in any distro, inclusive proprietary OS:s(Win,
>> Mac). Why shoujld pdf-tools be different then any other tool we use in
>> Emacs (binutils, compilers, debuggers, grep, ag, you-name-it)?
>
> I'm not quite sure I follow. We're talking about the Emacs package pdf-tools,
> which isn't used by other applications, because, well, it's an Emacs package.
> :-) The pdf-tools package uses a C program called epdfinfo to actually read the
> pdf and feed Emacs all the info it needs to display the pdf file. Epdfinfo is
> part of the pdf-tools package and needs to be compiled before you can use the 
> package in Emacs.
>
> Epdfinfo uses Poppler and in order for it to be built, a number of development
> requirements need to be installed. pdf-tools will try to install these through
> the system package manager, but this, too, can be done manually if you prefer.
>
> So Emacs is not being made into a package manager for .deb or .rpm files, the
> only thing that needs to be compiled is a C program that comes with the package.
Oh, I am sorry, it was too early after my beauty sleep, I should have
waited for more coffee slurps before I engage in any thought process. I
thought you were talking about a "pdftools" a package that comes with
some distros. I don't know why, my mind was in a wrong spot. My bad :-).

Re: Adding Emms to ELPA (take 2), and a technical question

[Basil L. Contovounesios]

Robert Pluim <rpluim@gmail.com> writes:

>>>>>> On Tue, 28 Apr 2020 09:28:56 -0400, Yoni Rabkin <yoni@rabkins.net> said:
>     >> Yes, there is.  You can put something like:
>     >> 
>     >> (eval-when-compile (call-process "make"))
>     >> 
>     >> in your main file, for example.
>
>     Yoni> We would need to make sure that there are compilation tools ready on the
>     Yoni> machine first.
>
> Iʼd take a look at 'pdf-tools', it both compiles C-code and installs
> necessary packages using 'apt-get' and similar.

Another package I recently came across with an external build step is
magit-libgit (specifically its dependency libgit).

-- 
Basil

Re: Adding Emms to ELPA (take 2), and a technical question

[Stefan Monnier]

> Another package I recently came across with an external build step is
> magit-libgit (specifically its dependency libgit).

As well as `emacs-tree-sitter`


        Stefan

Re: Adding Emms to ELPA (take 2), and a technical question

[Yoni Rabkin]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> The main issue back then was that Emms was a copyright mess. Stefan
>> Monnier helped me figuring out who to contact and I've fixed that since
>> (took a while). To the best of my knowledge, everyone who has code in
>> Emms has an assignment on file. Emms has an AUTHORS file which is kept
>> up-to-date. Everyone there should also appear in the FSF records.
>
> Great news, thank you!

Apologies for the delay on moving forward with this. I get limited
"epochs" to work on Emms, and those tend to be randomly distributed
throughout a given month.

I did some work, which I've described below. The goal is still to keep
the Emms files under Lisp and not to change the way Emms can be setup
outside of using elpa. For instance, I know that there are people who
package Emms for Debian and other OS' using their own package
managers. I don't want to rock their boat if possible.

>> Stefan also said that ELPA packages need to have their .el files at the
>> top-level.  However, Emms has its files in a lisp/ directory. This is
>> still the case, and I would like to keep it that way because Emms has a
>> lot of files and a lisp/ directory keeps things tidy. Is this still a
>> requirement for ELPA?
>
> Yes, and you even wrote it right: it's a property of ELPA (and not
> specific to GNU ELPA), so it affects MELPA just as well.  This comes
> from the fact that only top-level files are scanned for `;;;###autoload`
> cookies when the package is installed.
>
> You can work around this problem with extra work, tho: build your own
> autoloads file for the files in `lisp/*.el` and distribute it as if it
> were a "source" file.
>
> The Hyperbole package does that for its `kotl` subdirectory:
> they "manually" builds&updates a `kotl/kotl-autoloads.el` file (the rule
> to update it is in a Makefile), and then in `hyperbole.el` they have:
>
>     ;;;###autoload (load "kotl/kotl-autoloads" nil 'nowarn)

I made a file in the top-level of the emms distribution named
emms-elpa.el. emms-elpa.el contains the headers (Author, Version,
Package-Requires, etc.), followed by:

;;;###autoload (load "lisp/emms-auto" nil 'nowarn)

You can see it here:
https://git.savannah.gnu.org/cgit/emms.git/tree/emms-elpa.el

lisp/emms-auto.el is generated by lisp/Makefile to contain autoloads for
the .el files under lisp/

I don't understand how that would be enough to provide a valid load-path
to the files in the lisp/ directory though.

Unrelated to the above: the Makefile has been modified to generate a
"dir" file at the top-level with the appropriate info entry.
https://git.savannah.gnu.org/cgit/emms.git/tree/dir

>> Emms also comes with a small piece of code that needs to be compiled in
>> order to use taglib (https://taglib.org/). The code is in a src/
>> directory in the Emms distribution. I understand that there is no way to
>> get ELPA to compile something as a part of the installation.
>
> Yes, there is.  You can put something like:
>
>     (eval-when-compile (call-process "make"))
>
> in your main file, for example.
>
>> We can forgo any compilation at the ELPA installation stage as long as
>> people get to read the excellent Emms manual which explains how (and
>> why) to compile that bit of code.  Would any of this be a problem for
>> adding Emms to ELPA?
>
> These will require extra work on your part, but other than that, no,
> they don't impact your ability to add the package to GNU ELPA.
>
>> We (the Emms developers) are desperately looking for a better way to
>> give Emms access to taglib other than compiling glue code like we do
>> now. We really don't want to ship C, or C++, or Perl, or anything except
>> elisp with Emms. One option we are currently exploring is to ask the
>> user to install an existing package such as pytaglib (a GPLv3 python
>> wrapper around taglib). Is there any more elegant way to get access to
>> taglib through Emacs that anyone can suggest?
>
> I'm afraid I don't have a better solution to offer.

This should no longer be a problem going forward.

We have decided to depreciate the C "shim" program and instead provide
support for exiftool (perl-license-licensed perl script apt-gettable on
a fully free system), and tinytag (Expat-licensed python you can get via
pip, or manually install on a fully free system). The user will be
directed to install those on their system independently if they wish
that specific functionality.

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

Re: Adding Emms to ELPA (take 2), and a technical question

[Stefan Monnier]

> outside of using elpa. For instance, I know that there are people who
> package Emms for Debian and other OS' using their own package
> managers. I don't want to rock their boat if possible.

Those people can package ELPA packages their eyes closed (try `apt
search elpa-` to see why I think so). They will likely stop using their
ad-hoc packaging once it's available via GNU ELPA and will use their
generic support for packaging ELPA packages instead.

> I made a file in the top-level of the emms distribution named
> emms-elpa.el. emms-elpa.el contains the headers (Author, Version,
> Package-Requires, etc.), followed by:

The file that contains those headers *has* to be called <pkg>.el, so if
you call it `emms-elpa.el` the package will have to be called `emms-elpa`.

> ;;;###autoload (load "lisp/emms-auto" nil 'nowarn)

LGTM.

> You can see it here:
> https://git.savannah.gnu.org/cgit/emms.git/tree/emms-elpa.el
>
> lisp/emms-auto.el is generated by lisp/Makefile to contain autoloads for
> the .el files under lisp/

Perfect.

> I don't understand how that would be enough to provide a valid load-path
> to the files in the lisp/ directory though.

That won't be enough.  You probably want to add

    (add-to-list 'load-path (directory-file-name (or (file-name-directory load-file-name) (car load-path))))

to that `lisp/emms-auto.el` file.


        Stefan

Re: Adding Emms to ELPA (take 2), and a technical question

[Sean Whitton]

Hello,

Hope this is not too off-topic.

On Wed 27 May 2020 at 10:36PM -04, Stefan Monnier wrote:

>> outside of using elpa. For instance, I know that there are people who
>> package Emms for Debian and other OS' using their own package
>> managers. I don't want to rock their boat if possible.
>
> Those people can package ELPA packages their eyes closed (try `apt
> search elpa-` to see why I think so). They will likely stop using their
> ad-hoc packaging once it's available via GNU ELPA and will use their
> generic support for packaging ELPA packages instead.

Just fyi, the elpa-* machinery is independent of whether the package is
available in an ELPA archive, as we can generate the required metadata
mostly automatically.  But if upstream does provide the files, then it
tends to work a bit better.

The reason the emms package in Debian doesn't use that machinery yet is
simply that it hasn't been switched over to use it by its package
maintainer.

-- 
Sean Whitton

Re: Adding Emms to ELPA (take 2), and a technical question

[Yoni Rabkin]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> outside of using elpa. For instance, I know that there are people who
>> package Emms for Debian and other OS' using their own package
>> managers. I don't want to rock their boat if possible.
>
> Those people can package ELPA packages their eyes closed (try `apt
> search elpa-` to see why I think so). They will likely stop using their
> ad-hoc packaging once it's available via GNU ELPA and will use their
> generic support for packaging ELPA packages instead.
>
>> I made a file in the top-level of the emms distribution named
>> emms-elpa.el. emms-elpa.el contains the headers (Author, Version,
>> Package-Requires, etc.), followed by:
>
> The file that contains those headers *has* to be called <pkg>.el, so if
> you call it `emms-elpa.el` the package will have to be called `emms-elpa`.
>
>> ;;;###autoload (load "lisp/emms-auto" nil 'nowarn)
>
> LGTM.
>
>> You can see it here:
>> https://git.savannah.gnu.org/cgit/emms.git/tree/emms-elpa.el
>>
>> lisp/emms-auto.el is generated by lisp/Makefile to contain autoloads for
>> the .el files under lisp/
>
> Perfect.
>
>> I don't understand how that would be enough to provide a valid load-path
>> to the files in the lisp/ directory though.
>
> That won't be enough.  You probably want to add
>
>     (add-to-list 'load-path (directory-file-name (or (file-name-directory load-file-name) (car load-path))))
>
> to that `lisp/emms-auto.el` file.
>
>
>         Stefan

Does it makes sense for me to package Emms up in a ELPA-format archive,
load it into an local Emacs instance here, and see if it all works
before pinging the list again?

This would allow me to continue modifying things on my branch of Emms
here and check that it works for myself. All this without polluting the
main branch of Emms, or bugging y'all before everything is good to go.

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

Re: Adding Emms to ELPA (take 2), and a technical question

[Yoni Rabkin]

Emms is now being distributed via GNU ELPA. I wanted to take a moment to
thank Stefan Monnier for his work over the past weeks to make that
happen.

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