From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.ciao.gmane.io!not-for-mail From: Yoni Rabkin Newsgroups: gmane.emacs.devel Subject: Re: Adding Emms to ELPA (take 2), and a technical question Date: Wed, 27 May 2020 15:44:47 -0400 Message-ID: <87mu5trwls.fsf@rabkins.net> References: <87pnbwg0up.fsf@rabkins.net> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="ciao.gmane.io:159.69.161.202"; logging-data="70301"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.91 (gnu/linux) Cc: emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Wed May 27 21:46:02 2020 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1je201-000I9k-QQ for ged-emacs-devel@m.gmane-mx.org; Wed, 27 May 2020 21:46:01 +0200 Original-Received: from localhost ([::1]:40062 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1je200-0004XC-Re for ged-emacs-devel@m.gmane-mx.org; Wed, 27 May 2020 15:46:00 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:57468) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1je1yu-0003Qv-1f for emacs-devel@gnu.org; Wed, 27 May 2020 15:44:52 -0400 Original-Received: from smtprelay0080.hostedemail.com ([216.40.44.80]:55498 helo=smtprelay.hostedemail.com) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1je1ys-0003dl-Lv for emacs-devel@gnu.org; Wed, 27 May 2020 15:44:51 -0400 Original-Received: from filter.hostedemail.com (clb03-v110.bra.tucows.net [216.40.38.60]) by smtprelay08.hostedemail.com (Postfix) with ESMTP id 8DDCC180F0ED9; Wed, 27 May 2020 19:44:49 +0000 (UTC) X-Session-Marker: 796F6E69407261626B696E732E6E6574 X-HE-Tag: store41_160794526d54 X-Filterd-Recvd-Size: 5408 Original-Received: from birch.rabkins.net (c-73-238-99-162.hsd1.ma.comcast.net [73.238.99.162]) (Authenticated sender: yoni@rabkins.net) by omf11.hostedemail.com (Postfix) with ESMTPA; Wed, 27 May 2020 19:44:48 +0000 (UTC) X-Ethics: Use GNU In-Reply-To: (Stefan Monnier's message of "Fri, 24 Apr 2020 23:25:08 -0400") Received-SPF: none client-ip=216.40.44.80; envelope-from=yoni@rabkins.net; helo=smtprelay.hostedemail.com X-detected-operating-system: by eggs.gnu.org: First seen = 2020/05/27 15:44:49 X-ACL-Warn: Detected OS = Linux 3.11 and newer X-Spam_score_int: -18 X-Spam_score: -1.9 X-Spam_bar: - X-Spam_report: (-1.9 / 5.0 requ) BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, URIBL_BLOCKED=0.001 autolearn=_AUTOLEARN X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.io gmane.emacs.devel:251520 Archived-At: Stefan Monnier 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"