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

[Yoni Rabkin <yoni@rabkins.net>]

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"