GNU bug report logs - #66554
[PATCH] Add the public API of Compat to the core

Previous Next

Full log

Message #100 received at 66554 <at> debbugs.gnu.org (full text, mbox):

From: Philip Kaludercic <philipk <at> posteo.net>
To: Daniel Mendler <mail <at> daniel-mendler.de>
Cc: 66554 <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org>,
 monnier <at> iro.umontreal.ca, stefankangas <at> gmail.com
Subject: Re: bug#66554: [PATCH] Add the public API of Compat to the core
Date: Thu, 18 Jan 2024 19:51:27 +0000

[Message part 1 (text/plain, inline)]

Daniel Mendler <mail <at> daniel-mendler.de> writes:

> Eli Zaretskii <eliz <at> gnu.org> writes:
>
>>> From: Philip Kaludercic <philipk <at> posteo.net>
>>> Cc: Daniel Mendler <mail <at> daniel-mendler.de>,  66554 <at> debbugs.gnu.org,
>>>   monnier <at> iro.umontreal.ca,  stefankangas <at> gmail.com
>>> Date: Fri, 12 Jan 2024 22:27:37 +0000
>>> 
>>> Eli Zaretskii <eliz <at> gnu.org> writes:
>>> 
>>> >> > I guess I'm misunderstanding something.  The scenario that I have in
>>> >> > mind is this:
>>> >> >
>>> >> >   . we bump Emacs version to NN.1.90 as part of pretesting version NN.2
>>> >> >   . as part of the pretest, some function changes that requires
>>> >> >     addition or change in compat.el
>>> >> >   . compat.el still claims version NN.1, although it includes changes
>>> >> >     not present in Emacs NN.1
>>> >> >
>>> >> > Did I succeed in explaining my worries?
>>> >> 
>>> >> I hope I understood your reasoning correctly. Shortly after you bump
>>> >> NN.1.90 we can release compat-NN.2.0 which will include the necessary
>>> >> change.
>>> >
>>> > Release where? on ELPA or as part of the Emacs tarball?
>>> >
>>> > And how do we make sure we will not forget to release this new version
>>> > of compat.el?
>>> 
>>> We have to distinguish the ELPA package Compat and the compat.el file
>>> being added here.
>>
>> Yes, we should.  I'm asking exactly that: when you say "we can release
>> compat-NN.2.0", do you mean ELPA or do you mean compat.el in Emacs?
>
> In this case we mean compat-NN.2.0 on ELPA.
>
>>> The ELPA package Compat is manually released on our
>>> behalf, usually after a release of Emacs has been announced.  The plan
>>> is that the compat.el file does not have to be touched at all, since it
>>> registers itself to use the right version, while Emacs is scraping the
>>> for autoloads.  So there shouldn't be any additional effort from the
>>> side of Emacs maintenance, and nothing one can "forget".
>>
>> But that's exactly the problem I'm struggling with: compat.el in Emacs
>> registers itself with inaccurate version, which lacks the last part
>> after emacs-minor.
>
> The internal compat.el in Emacs does not register itself with an
> inaccurate version. The version of compat.el in Emacs for a version NN.x
> is always the newest version one can get by definition.
>
> If the Emacs version is 30.1, the version of the internal compat.el is
> 30.1.most-positive-fixnum. This means the internal compat.el is
> considered newer than any compat-30.1.x on ELPA. The reasoning is that
> compat-30.1.x on ELPA cannot provide anything newer which is not already
> in Emacs 30.1, and as such it is not necessary to install it.
>
> However if there exists a compat-30.2.x on ELPA, then this package will
> take precendence over the internal compat.el with version
> 30.1.most-positive-fixnum. Then the ELPA package compat-30.2.x can get
> installed on an Emacs 30.1, if depended on by another ELPA package,
> e.g., Magit.
>
> For example let's assume that Magit depends on compat-30.2. Note that
> this dependency can either be satisfied by an ELPA compat-30.2.x or by
> an internal compat.el with version 30.2.most-positive-fixnum. Magit
> wants to take advantage of new APIs or API changes introduced in Emacs
> 30.2, which are also made available by ELPA compat-30.2. This means in
> this case ELPA compat-30.2.x must be installed if the internal compat.el
> has version 30.1.most-positive-fixnum.
>
>> As for "forgetting", I do mean whoever should remember to release a
>> new version of Compat on ELPA -- if this is a manual operation, it can
>> be forgotten, especially if it has to be related to pretest releases
>> as well as the official releases.
>
> Currently I am responsible of releasing new versions of Compat to ELPA.
> But there is no risk of forgetting, or rather, it is okay to not release
> new ELPA Compat versions immediately. There can be a time window.
>
> In the scenario described above, Magit wants to depend on compat-30.2.
> Since Magit itself is released on ELPA, the package can only be
> installed when compat-30.2 is available on ELPA. This means that Jonas
> will only start to depend on compat-30.2 after I've released it to ELPA.
> Before that has happened, Magit cannot take advantage of features which
> have been introduced in Emacs 30.2.
>
>> I guess I lack an overall picture of how this is supposed to work, as
>> part of our pretest and release flow.  Could you or someone else post
>> such a complete description?  Without this, I'm not sure I agree with
>> the changes being considered, or at least don't quite understand their
>> impact on the routine maintenance.
>
> The inclusion of compat.el into Emacs won't have an impact on the Emacs
> pretest or release flow. The Compat ELPA package can be released
> independently as I described above. There are these reasons why we are
> proposing the small compat.el file for inclusion:
>
> 1. It will be easier for :core packages which are available on ELPA to
> take advantage of Compat. They can (require 'compat) and they don't have
> to use (require 'compat nil 'noerror).
>
> 2. Core packages which use Compat do not have to replicate the
> `compat-function' and `compat-call' macros in their own code. See
> erc-compat.el for a core package, where these macros are already
> duplicated with the names `erc-compat-function' and `erc-compat-call'.
> Instead of this replication, erc-compat.el can just (require 'compat)
> and use `compat-function' and `compat-call'.
>
> 3. Compat should not be installed automatically as dependency if Emacs
> itself already provides the required API. For example on Emacs 30.1 I do
> not want to install compat-30.1 from ELPA, since Emacs itself already
> provides everything compat-30.1.x from ELPA ever could provide. Emacs is
> in charge of the API definition and Compat won't add anything itself.
>
> Now to describe the pretest or release flows - the Emacs release flow
> can proceeds as usual, as it has happened before with 28.1, 28.2, 29.1
> etc. The compat.el file as part of Emacs will not have to be updated or
> changed.
>
> The ELPA package Compat will be released independently. After a release
> of pretest Emacs-30.0 we may release Compat-30.0.x on ELPA. This does
> not have to happen immediately. Only after Compat-30.0.x has landed on
> ELPA, other ELPA packages (which for example depend on Emacs 26.1 as
> base line) may start to depend on compat-30.0 and start using new Emacs
> 30.0 functions or macros, e.g., `static-if'. Before the release of
> Compat, an external package cannot take advantage of `static-if', since
> the ELPA Compat does not provide it yet, and the base line Emacs 26.1
> does not provide it.
>
> Note that Compat on ELPA is already used by many packages exactly in the
> way I've described. The inclusion of compat.el in Emacs will smoothen
> the situation for core packages (which are also released to ELPA) and
> will ensure that no unnecessary Compat package is installed, the points
> 1, 2 and 3 I listed above.
>
> Daniel

Pinging this thread with an updated version of the patch:

[0001-Add-the-public-API-of-Compat-to-the-core.patch (text/x-diff, attachment)]

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.