From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Philip Kaludercic Newsgroups: gmane.emacs.devel Subject: Re: having emacs-matlab in ELPA, finally. FSF paper signed Date: Sun, 24 Nov 2024 19:59:30 +0000 Message-ID: <87mshotnbx.fsf@posteo.net> References: <871q37um8q.fsf@mat.ucm.es> <87v80cp8nx.fsf@mat.ucm.es> <877ccmkmwy.fsf@posteo.net> <87bk1y0wcm.fsf@mat.ucm.es> <87o75xkjpj.fsf@posteo.net> <874j3z8cy5.fsf@mat.ucm.es> <87ldxansy5.fsf@posteo.net> <87y11a13vx.fsf@mat.ucm.es> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="11907"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Uwe Brauer , Andrea Corallo , emacs-devel@gnu.org To: Stefan Kangas Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sun Nov 24 21:00:36 2024 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 1tFImZ-0002wX-JS for ged-emacs-devel@m.gmane-mx.org; Sun, 24 Nov 2024 21:00:35 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1tFIlk-00075q-3W; Sun, 24 Nov 2024 14:59:44 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1tFIlh-00075a-Im for emacs-devel@gnu.org; Sun, 24 Nov 2024 14:59:41 -0500 Original-Received: from mout02.posteo.de ([185.67.36.66]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1tFIld-0006KI-DK for emacs-devel@gnu.org; Sun, 24 Nov 2024 14:59:40 -0500 Original-Received: from submission (posteo.de [185.67.36.169]) by mout02.posteo.de (Postfix) with ESMTPS id EE891240101 for ; Sun, 24 Nov 2024 20:59:32 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017; t=1732478372; bh=MzfNPrHYnuA9C+QemoITxQ/GNCcO2K2CD3ng847wCRI=; h=From:To:Cc:Subject:Autocrypt:OpenPGP:Date:Message-ID:MIME-Version: Content-Type:From; b=aoofaoylCfpTcSyp3WgdsvZTibve1R2EZuysvVu6x+ht4oi7UDRkoiV7UDXEDby72 VM9ujEo71VG9cjkJxtvazMNWPCzrPE2sXUw92zpl8+YHsWbmAFbEKwmFeivfRg0VNy QjbF9lcW2EQR/45Ocowg/t62O5eVdpy0FFZWfUkjquRRIsGQbAi1nd2eUKSeDzOiJG ik3XgeuwqWK/opXw6e8JgnNIvIx83eAL5exXjr3dNtFiPGIqDo2aeBlI1wTKkzvkDF A+kh84mAQGZI/jlfWQU8ilfceqZKt4Jb3TwhKU4N3Fw8iv6zMa5KY38l/lCbo4vzD0 kvM9Sl+jqAilw== Original-Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4XxKRl53N4z9rxD; Sun, 24 Nov 2024 20:59:31 +0100 (CET) In-Reply-To: (Stefan Kangas's message of "Sat, 23 Nov 2024 14:13:51 -0500") Autocrypt: addr=philipk@posteo.net; keydata= mDMEZBBQQhYJKwYBBAHaRw8BAQdAHJuofBrfqFh12uQu0Yi7mrl525F28eTmwUDflFNmdui0QlBo aWxpcCBLYWx1ZGVyY2ljIChnZW5lcmF0ZWQgYnkgYXV0b2NyeXB0LmVsKSA8cGhpbGlwa0Bwb3N0 ZW8ubmV0PoiWBBMWCAA+FiEEDg7HY17ghYlni8XN8xYDWXahwukFAmQQUEICGwMFCQHhM4AFCwkI BwIGFQoJCAsCBBYCAwECHgECF4AACgkQ8xYDWXahwulikAEA77hloUiSrXgFkUVJhlKBpLCHUjA0 mWZ9j9w5d08+jVwBAK6c4iGP7j+/PhbkxaEKa4V3MzIl7zJkcNNjHCXmvFcEuDgEZBBQQhIKKwYB BAGXVQEFAQEHQI5NLiLRjZy3OfSt1dhCmFyn+fN/QKELUYQetiaoe+MMAwEIB4h+BBgWCAAmFiEE Dg7HY17ghYlni8XN8xYDWXahwukFAmQQUEICGwwFCQHhM4AACgkQ8xYDWXahwukm+wEA8cml4JpK NeAu65rg+auKrPOP6TP/4YWRCTIvuYDm0joBALw98AMz7/qMHvSCeU/hw9PL6u6R2EScxtpKnWof z4oM OpenPGP: id=philipk@posteo.net; url="https://keys.openpgp.org/vks/v1/by-email/philipk@posteo.net"; preference=signencrypt Received-SPF: pass client-ip=185.67.36.66; envelope-from=philipk@posteo.net; helo=mout02.posteo.de X-Spam_score_int: -43 X-Spam_score: -4.4 X-Spam_bar: ---- X-Spam_report: (-4.4 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RCVD_IN_VALIDITY_CERTIFIED_BLOCKED=0.001, RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 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-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.devel:325674 Archived-At: Stefan Kangas writes: > Uwe Brauer writes: > >>>>> "SK" == Stefan Kangas writes: >> >>> Philip Kaludercic writes: >>>> +(defconst matlab-mode-version (package-get-version) >>>> + "Current version of MATLAB(R) mode.") >> >>> We have tried to discourage the addition of such variables and commands, >>> given that one can always find that information by other means, >>> e.g. interactively with `describe-package` or from Lisp: >> >>> (package-desc-version (cadr (assq 'foo package-alist))) >> >> So you want me use just that string >> well (package-desc-version (cadr (assq 'matlab-mode package-alist))) >> I presume >> >> in matlab.el (and matlab-mode.el)? > > That's what I would do, indeed. Well, I'd use this if you need the > string form: > > (package-version-join > (package-desc-version (cadr (assq 'matlab-mode package-alist)))) We should keep in mind that this will break if the package is not installed using package.el, as then (cadr (assq 'matlab-mode package-alist)) ;=> nil and thus (package-desc-version nil) ;!> (wrong-type-argument package-desc nil) > Yeah, it's a bit of a mouthful. Most packages don't bother, and just > rely on `describe-package`, I think. > > That said, there's nothing wrong with keeping it around; it just seems > redundant now that you have a "Version" header. I mostly mentioned it > for the record, and in case you wanted to get rid of some possible > redundancy. > > (Personally, I'm not sure if the `matlab-show-version` command is needed > either given that we have `describe-package`. In emacs.git, we tend to > make such `foo-package-version` commands obsolete.) 1+ to this. The custom commands for version numbers are an anti-pattern IMO. > >> What's about our current setting >> >> (defconst matlab-mode-version "6.2" >> "Current version of MATLAB(R) mode.") >> >> Which we need for MELPA? > > Hmm, are you sure that you need it for MELPA even with the addition of > the "Version" header? > > In any case, this is an extremely minor nit either way. Uwe Brauer via Matlab-emacs-discuss writes: >> Uwe Brauer writes: > >> You don't have to do anything*, I just have to add a package >> specification (similar to the "recipe file" for MELPA) to elpa.git. > >> * As soon as it works. The main issues right now, are as you noticed >> that ELPA doesn't release a new tarball for every commit, but just >> when a new version is released. We track this by checking for commits >> that bump the "Version" header in the main file (in your case >> matlab.el). You currently don't have any version number, so the build >> fails. I would suggest applying a change like this, if it doesn't >> break any assumptions you have regarding the minimal Emacs version: > >> diff --git a/matlab.el b/matlab.el >> index 8ca0ee24a2..b82229a672 100644 >> --- a/matlab.el >> +++ b/matlab.el >> @@ -5,11 +5,7 @@ >> ;; Maintainer: Eric M. Ludlam >> ;; Created: 04 Jan 91 >> ;; Keywords: MATLAB(R) >> -;; Version: >> - >> -(defconst matlab-mode-version "5.0" >> - "Current version of MATLAB(R) mode.") >> - >> +;; Version: 5.0 >> ;; >> ;; Copyright (C) 1997-2022 Eric M. Ludlam >> ;; Copyright (C) 1991-1997 Matthew R. Wette >> @@ -50,6 +46,10 @@ > >> ;;; Code: > >> +(defconst matlab-mode-version (package-get-version) >> + "Current version of MATLAB(R) mode.") >> + >> + >> (require 'matlab-compat) >> (require 'matlab-syntax) >> (require 'matlab-scan) > > A couple of remarks, > > 1. this diff seems against an older matlab-mode version (may the one > in sourceforge), the latest github version is 6.2 > https://github.com/mathworks/Emacs-MATLAB-Mode.git That might very well be, I used a local checkout that ELPA made when experimenting with the package, and it appears that was not the newest version. > 2. Jonas Bernoulli one of the MELPA maintainers, recommended (but > did not demand) to add file called matlab-mode.el which is > basically a dummy file but also contains the current version What is the name of the MELPA package? If it is called "matlab", then by default ELPA will consult the "matlab.el" file for version information. Otherwise it will consult "matlab-mode.el". We can adjust this though if need be in the package specification. >> The other issue is that ELPA checks the copyright string and wants to >> see that all packages in GNU ELPA have their copyright assigned to the >> FSF. > > There is an automated process for checking this. If I had known, it > would have saved my quite a bit of time and work. I eyeballed the logs > and if there was an unknown author I checked the diff, and if necessary > contacted him. It doesn't go through the logs, it just searches for a copyright string somewhere in the header. >> If you can fix these two things, then everything should go through. >> You can then decide to filter out files out of the final tarball by >> adding an .elpaignore file that lists what files to exclude. > > > 1. I will add an elpaignore file, which is urgent, > > 2. And concerning the version number, what shall I do, your proposal > or Stefan's? > > For the moment being I would like to keep the MELPA version as well till > I know ELPA works Inherently there is no reason against having both, especially if people have already installed the package via MELPA. > Uwe Uwe Brauer writes: >> Uwe Brauer writes: > > >> +(defconst matlab-mode-version (package-get-version) >> + "Current version of MATLAB(R) mode.") >> + >> + >> (require 'matlab-compat) >> (require 'matlab-syntax) >> (require 'matlab-scan) > > >> The other issue is that ELPA checks the copyright string and wants to >> see that all packages in GNU ELPA have their copyright assigned to the >> FSF. > >> If you can fix these two things, then everything should go through. >> You can then decide to filter out files out of the final tarball by >> adding an .elpaignore file that lists what files to exclude. > > I added .elpaignore, > and pushed the commit to the github repository. 1+ > Concerning the version header, I got two different recommendation so I > prefer to wait till this is settled, and also what to do with the > original string that is needed for MELPA > > >> We have tried to discourage the addition of such variables and commands, >> given that one can always find that information by other means, >> e.g. interactively with `describe-package` or from Lisp: > >> (package-desc-version (cadr (assq 'foo package-alist)))