GNU bug report logs - #77075
[PATCH] Prepare package.el to be published on GNU ELPA

Previous Next

To reply to this bug, email your comments to 77075 AT debbugs.gnu.org.

Toggle the display of automated, internal messages from the tracker.

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

From: Philip Kaludercic <philipk <at> posteo.net>
To: bug-gnu-emacs <at> gnu.org
Subject: [PATCH] Prepare package.el to be published on GNU ELPA
Date: Mon, 17 Mar 2025 17:32:42 +0000

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

Tags: patch


Hi, I am attaching a patch from emacs-devel that was written two years
ago, where we discussed the possibility of adding package.el to ELPA.
There is a minor difference here, I propose setting the version to
1.1.1-pre, so as to prevent an immediate release on ELPA.  It should be
possible to gather some feedback from ELPA devel users before committing
to a final release.

As far as I am aware, the main objection to this idea is that this might
introduce instability that is difficult to fix (If `package-delete'
doesn't work, then it isn't obvious how to uninstall the newer
package.el).  Are there any other points we should discuss?

In GNU Emacs 31.0.50 (build 4, x86_64-pc-linux-gnu, GTK+ Version
 3.24.48, cairo version 1.18.2) of 2025-03-12 built on siskin
Repository revision: 7c9ec8a56549740718bf764c9cefca648c45ea84
Repository branch: master
Windowing system distributor 'The X.Org Foundation', version 11.0.12401006
System Description: Debian GNU/Linux trixie/sid

[0001-Prepare-package.el-to-be-published-on-GNU-ELPA.patch (text/patch, attachment)]

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

From: Daniel Mendler <mail <at> daniel-mendler.de>
To: Philip Kaludercic <philipk <at> posteo.net>
Cc: 77075 <at> debbugs.gnu.org, Stefan Monnier <monnier <at> iro.umontreal.ca>
Subject: Re: bug#77075: [PATCH] Prepare package.el to be published on GNU
 ELPA, [PATCH] Prepare package.el to be published on GNU ELPA
Date: Mon, 17 Mar 2025 19:39:00 +0100

Hi Philip,

a few comments below.

> diff --git a/lisp/emacs-lisp/package.el b/lisp/emacs-lisp/package.el
> index 8d2e2f09108..7a69e680880 100644
> --- a/lisp/emacs-lisp/package.el
> +++ b/lisp/emacs-lisp/package.el
> @@ -5,9 +5,12 @@
>  ;; Author: Tom Tromey <tromey <at> redhat.com>
>  ;;         Daniel Hackney <dan <at> haxney.org>
>  ;; Created: 10 Mar 2007
> -;; Version: 1.1.0
> +;; Version: 1.1.1-pre
>  ;; Keywords: tools
> -;; Package-Requires: ((tabulated-list "1.0"))
> +;; Package-Requires: ((emacs "26.1") (compat "29"))

I suggest to require the newest Compat 30.

> +;; This is a GNU ELPA :core package.  Avoid functionality that is not
> +;; compatible with the version of Emacs recorded above.
>  
>  ;; This file is part of GNU Emacs.
>  
> @@ -147,6 +150,7 @@
>  (eval-when-compile (require 'subr-x))
>  (eval-when-compile (require 'epg))      ;For setf accessors.
>  (eval-when-compile (require 'inline))   ;For `define-inline'
> +(require 'compat nil 'noerror)
>  (require 'seq)

(require 'compat) without the noerror argument should work, since we
have the compat.el stub in Emacs.

>  (require 'tabulated-list)
> @@ -1151,7 +1155,8 @@ package--native-compile-async
>    "Native compile installed package PKG-DESC asynchronously.
>  This assumes that `pkg-desc' has already been activated with
>  `package-activate-1'."
> -  (when (native-comp-available-p)
> +  (when (and (fboundp 'native-comp-available-p)
> +             (native-comp-available-p))
>      (let ((warning-minimum-level :error))
>        (native-compile-async (package-desc-dir pkg-desc) t))))

`native-comp-available-p' is provided by Compat. You can use it
directly. It aliases `ignore' on Emacs 27 and older.

>        ;; Insert news if available.
>        (when news
> -        (insert "\n" (make-separator-line) "\n"
> -                (propertize "* News" 'face 'package-help-section-name)
> +        (insert "\n" (make-separator-line) "\n")
> +        (when (fboundp 'make-separator-line)
> +          (insert (make-separator-line) "\n"))
> +        (insert (propertize "* News" 'face 'package-help-section-name)
>                  "\n\n")
>          (insert-file-contents news))

`make-separator-line' is provided by Compat.

Daniel

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

From: Philip Kaludercic <philipk <at> posteo.net>
To: Daniel Mendler <mail <at> daniel-mendler.de>
Cc: 77075 <at> debbugs.gnu.org, Stefan Monnier <monnier <at> iro.umontreal.ca>
Subject: Re: bug#77075: [PATCH] Prepare package.el to be published on GNU
 ELPA, [PATCH] Prepare package.el to be published on GNU ELPA
Date: Mon, 17 Mar 2025 20:28:32 +0000

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

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

> Hi Philip,
>
> a few comments below.

Thanks for the reminders, I've update the patch!

[0001-Prepare-package.el-to-be-published-on-GNU-ELPA.patch (text/x-diff, attachment)]

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

>> diff --git a/lisp/emacs-lisp/package.el b/lisp/emacs-lisp/package.el
>> index 8d2e2f09108..7a69e680880 100644
>> --- a/lisp/emacs-lisp/package.el
>> +++ b/lisp/emacs-lisp/package.el
>> @@ -5,9 +5,12 @@
>>  ;; Author: Tom Tromey <tromey <at> redhat.com>
>>  ;;         Daniel Hackney <dan <at> haxney.org>
>>  ;; Created: 10 Mar 2007
>> -;; Version: 1.1.0
>> +;; Version: 1.1.1-pre
>>  ;; Keywords: tools
>> -;; Package-Requires: ((tabulated-list "1.0"))
>> +;; Package-Requires: ((emacs "26.1") (compat "29"))
>
> I suggest to require the newest Compat 30.
>
>> +;; This is a GNU ELPA :core package.  Avoid functionality that is not
>> +;; compatible with the version of Emacs recorded above.
>>  
>>  ;; This file is part of GNU Emacs.
>>  
>> @@ -147,6 +150,7 @@
>>  (eval-when-compile (require 'subr-x))
>>  (eval-when-compile (require 'epg))      ;For setf accessors.
>>  (eval-when-compile (require 'inline))   ;For `define-inline'
>> +(require 'compat nil 'noerror)
>>  (require 'seq)
>
> (require 'compat) without the noerror argument should work, since we
> have the compat.el stub in Emacs.
>
>>  (require 'tabulated-list)
>> @@ -1151,7 +1155,8 @@ package--native-compile-async
>>    "Native compile installed package PKG-DESC asynchronously.
>>  This assumes that `pkg-desc' has already been activated with
>>  `package-activate-1'."
>> -  (when (native-comp-available-p)
>> +  (when (and (fboundp 'native-comp-available-p)
>> +             (native-comp-available-p))
>>      (let ((warning-minimum-level :error))
>>        (native-compile-async (package-desc-dir pkg-desc) t))))
>
> `native-comp-available-p' is provided by Compat. You can use it
> directly. It aliases `ignore' on Emacs 27 and older.
>
>>        ;; Insert news if available.
>>        (when news
>> -        (insert "\n" (make-separator-line) "\n"
>> -                (propertize "* News" 'face 'package-help-section-name)
>> +        (insert "\n" (make-separator-line) "\n")
>> +        (when (fboundp 'make-separator-line)
>> +          (insert (make-separator-line) "\n"))
>> +        (insert (propertize "* News" 'face 'package-help-section-name)
>>                  "\n\n")
>>          (insert-file-contents news))
>
> `make-separator-line' is provided by Compat.
>
> Daniel

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

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Daniel Mendler <mail <at> daniel-mendler.de>
Cc: Philip Kaludercic <philipk <at> posteo.net>, 77075 <at> debbugs.gnu.org
Subject: Re: bug#77075: [PATCH] Prepare package.el to be published on GNU
 ELPA, [PATCH] Prepare package.el to be published on GNU ELPA
Date: Mon, 17 Mar 2025 19:13:03 -0400

>> -;; Package-Requires: ((tabulated-list "1.0"))
>> +;; Package-Requires: ((emacs "26.1") (compat "29"))
> I suggest to require the newest Compat 30.

Is there a particular technical need for it?
As usual, I recommend we don't unnecessarily tighten dependencies.


        Stefan

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

From: Daniel Mendler <mail <at> daniel-mendler.de>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: Philip Kaludercic <philipk <at> posteo.net>, 77075 <at> debbugs.gnu.org
Subject: Re: bug#77075: [PATCH] Prepare package.el to be published on GNU
 ELPA, [PATCH] Prepare package.el to be published on GNU ELPA
Date: Tue, 18 Mar 2025 06:26:15 +0100

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

>>> -;; Package-Requires: ((tabulated-list "1.0"))
>>> +;; Package-Requires: ((emacs "26.1") (compat "29"))
>> I suggest to require the newest Compat 30.
>
> Is there a particular technical need for it?
> As usual, I recommend we don't unnecessarily tighten dependencies.

For builtin packages, which are published on ELPA, I recommend to
require the newest available Compat such that more APIs are available.
Sometimes it happens that unavailable APIs are required accidentally
when the Emacs code is updated in bulk.

Alternatively one can check what is provided exactly by the given Compat
version. package-lint provides an API version check and has Compat
support. It warns if an API is used which is not available by the
specified Emacs or Compat version.

Daniel

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

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Daniel Mendler <mail <at> daniel-mendler.de>
Cc: Philip Kaludercic <philipk <at> posteo.net>, 77075 <at> debbugs.gnu.org
Subject: Re: bug#77075: [PATCH] Prepare package.el to be published on GNU
 ELPA, [PATCH] Prepare package.el to be published on GNU ELPA
Date: Tue, 18 Mar 2025 11:55:14 -0400

>>>> -;; Package-Requires: ((tabulated-list "1.0"))
>>>> +;; Package-Requires: ((emacs "26.1") (compat "29"))
>>> I suggest to require the newest Compat 30.
>> Is there a particular technical need for it?
>> As usual, I recommend we don't unnecessarily tighten dependencies.
> For builtin packages, which are published on ELPA, I recommend to
> require the newest available Compat such that more APIs are available.
> Sometimes it happens that unavailable APIs are required accidentally
> when the Emacs code is updated in bulk.

Right, but there is also a "quality of service" desire to avoid
unnecessarily strict `package-requires:`.

> Alternatively one can check what is provided exactly by the given Compat
> version.  Package-lint provides an API version check and has Compat
> support.  It warns if an API is used which is not available by the
> specified Emacs or Compat version.

Maybe it could also point out when the specified requirements seem to be
more strict than necessary?


        Stefan

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

From: Philip Kaludercic <philipk <at> posteo.net>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: Daniel Mendler <mail <at> daniel-mendler.de>, 77075 <at> debbugs.gnu.org
Subject: Re: bug#77075: [PATCH] Prepare package.el to be published on GNU
 ELPA, [PATCH] Prepare package.el to be published on GNU ELPA
Date: Tue, 18 Mar 2025 17:32:30 +0000

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

>>>>> -;; Package-Requires: ((tabulated-list "1.0"))
>>>>> +;; Package-Requires: ((emacs "26.1") (compat "29"))
>>>> I suggest to require the newest Compat 30.
>>> Is there a particular technical need for it?
>>> As usual, I recommend we don't unnecessarily tighten dependencies.
>> For builtin packages, which are published on ELPA, I recommend to
>> require the newest available Compat such that more APIs are available.
>> Sometimes it happens that unavailable APIs are required accidentally
>> when the Emacs code is updated in bulk.
>
> Right, but there is also a "quality of service" desire to avoid
> unnecessarily strict `package-requires:`.
>
>> Alternatively one can check what is provided exactly by the given Compat
>> version.  Package-lint provides an API version check and has Compat
>> support.  It warns if an API is used which is not available by the
>> specified Emacs or Compat version.
>
> Maybe it could also point out when the specified requirements seem to be
> more strict than necessary?

Does it matter much in the end, considering that package.el will fetch
the newest version from ELPA, if any satisfactory version is available?

>
>         Stefan

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

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Philip Kaludercic <philipk <at> posteo.net>
Cc: Daniel Mendler <mail <at> daniel-mendler.de>, 77075 <at> debbugs.gnu.org
Subject: Re: bug#77075: [PATCH] Prepare package.el to be published on GNU
 ELPA, [PATCH] Prepare package.el to be published on GNU ELPA
Date: Tue, 18 Mar 2025 14:08:30 -0400

>>> Alternatively one can check what is provided exactly by the given Compat
>>> version.  Package-lint provides an API version check and has Compat
>>> support.  It warns if an API is used which is not available by the
>>> specified Emacs or Compat version.
>> Maybe it could also point out when the specified requirements seem to be
>> more strict than necessary?
> Does it matter much in the end, considering that package.el will fetch
> the newest version from ELPA, if any satisfactory version is available?

I'm worried that our standard practice is being polluted by other
systems where it's routine to force all users to constantly upgrade
everything (which I believe ultimately erodes the freedoms offered by
Free Software), so I think it's important that the packages over which
we have some control preserve the tradition of being careful to keep
dependencies no stricter than necessary.


        Stefan

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

From: Philip Kaludercic <philipk <at> posteo.net>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: Daniel Mendler <mail <at> daniel-mendler.de>, 77075 <at> debbugs.gnu.org
Subject: Re: bug#77075: [PATCH] Prepare package.el to be published on GNU
 ELPA, [PATCH] Prepare package.el to be published on GNU ELPA
Date: Tue, 18 Mar 2025 18:33:00 +0000

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

>>>> Alternatively one can check what is provided exactly by the given Compat
>>>> version.  Package-lint provides an API version check and has Compat
>>>> support.  It warns if an API is used which is not available by the
>>>> specified Emacs or Compat version.
>>> Maybe it could also point out when the specified requirements seem to be
>>> more strict than necessary?
>> Does it matter much in the end, considering that package.el will fetch
>> the newest version from ELPA, if any satisfactory version is available?
>
> I'm worried that our standard practice is being polluted by other
> systems where it's routine to force all users to constantly upgrade
> everything (which I believe ultimately erodes the freedoms offered by
> Free Software), so I think it's important that the packages over which
> we have some control preserve the tradition of being careful to keep
> dependencies no stricter than necessary.

I agree entirely (anecdotally+tangentially, I've recently been using a
offline system where I can only download packages via my web browser and
copying them onto the system via "scp", and installing packages with any
dependencies is a major annoyance), but in current case, it seems
unfeasible to publish package.el on ELPA that is still usable on older
releases without the help of Compat.  I would certainly oppose adding
any additional dependencies, and luckily in the future it might be
unnecessary to install Compat given the stub we have added in Emacs 30. 

>
>         Stefan

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

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Philip Kaludercic <philipk <at> posteo.net>
Cc: Daniel Mendler <mail <at> daniel-mendler.de>, 77075 <at> debbugs.gnu.org
Subject: Re: bug#77075: [PATCH] Prepare package.el to be published on GNU
 ELPA, [PATCH] Prepare package.el to be published on GNU ELPA
Date: Tue, 18 Mar 2025 14:45:44 -0400

> I agree entirely (anecdotally+tangentially, I've recently been using a
> offline system where I can only download packages via my web browser and
> copying them onto the system via "scp", and installing packages with any
> dependencies is a major annoyance), but in current case, it seems
> unfeasible to publish package.el on ELPA that is still usable on older
> releases without the help of Compat.  I would certainly oppose adding
> any additional dependencies, and luckily in the future it might be
> unnecessary to install Compat given the stub we have added in Emacs 30. 

Note that I'm not discussing which packages we depend on, or which
features we use in the code.  I'm focusing on which versions we put in
`Package-Requires:`, because I've seen recently an increase in commits
that do nothing but bump one of those versions.  Sometimes it's
warranted, of course (it fixes a bug because the bump was made necessary
by an earlier change), but I want to resist against making such changes
"just because".


        Stefan

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

From: Stefan Kangas <stefankangas <at> gmail.com>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>,
 Philip Kaludercic <philipk <at> posteo.net>
Cc: Daniel Mendler <mail <at> daniel-mendler.de>, 77075 <at> debbugs.gnu.org
Subject: Re: bug#77075: [PATCH] Prepare package.el to be published on GNU
 ELPA, [PATCH] Prepare package.el to be published on GNU ELPA
Date: Tue, 18 Mar 2025 15:50:19 -0700

Stefan Monnier via "Bug reports for GNU Emacs, the Swiss army knife of
text editors" <bug-gnu-emacs <at> gnu.org> writes:

> I'm worried that our standard practice is being polluted by other
> systems where it's routine to force all users to constantly upgrade
> everything (which I believe ultimately erodes the freedoms offered by
> Free Software), so I think it's important that the packages over which
> we have some control preserve the tradition of being careful to keep
> dependencies no stricter than necessary.

Could you perhaps briefly explain the philosophical argument?

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

From: Stefan Kangas <stefankangas <at> gmail.com>
To: Philip Kaludercic <philipk <at> posteo.net>, 77075 <at> debbugs.gnu.org
Cc: Stefan Monnier <monnier <at> iro.umontreal.ca>
Subject: Re: bug#77075: [PATCH] Prepare package.el to be published on GNU ELPA
Date: Tue, 18 Mar 2025 15:51:46 -0700

Philip Kaludercic <philipk <at> posteo.net> writes:

> As far as I am aware, the main objection to this idea is that this might
> introduce instability that is difficult to fix (If `package-delete'
> doesn't work, then it isn't obvious how to uninstall the newer
> package.el).  Are there any other points we should discuss?

Can you summarize what is our reply to that?  Do we have a better
workaround than `rm -rf ~/.emacs.d/elpa`?

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

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Stefan Kangas <stefankangas <at> gmail.com>
Cc: Daniel Mendler <mail <at> daniel-mendler.de>,
 Philip Kaludercic <philipk <at> posteo.net>, 77075 <at> debbugs.gnu.org
Subject: Re: bug#77075: [PATCH] Prepare package.el to be published on GNU
 ELPA, [PATCH] Prepare package.el to be published on GNU ELPA
Date: Tue, 18 Mar 2025 20:02:42 -0400

>> I'm worried that our standard practice is being polluted by other
>> systems where it's routine to force all users to constantly upgrade
>> everything (which I believe ultimately erodes the freedoms offered by
>> Free Software), so I think it's important that the packages over which
>> we have some control preserve the tradition of being careful to keep
>> dependencies no stricter than necessary.
>
> Could you perhaps briefly explain the philosophical argument?

Not sure what you mean by that, but if you want me to explain why
I think it erodes Free Software: in systems like Rust/Go/JS where
dependencies tend to be very tight, it becomes a lot more difficult to
maintain local changes to a piece of code, because pretty quickly none
of the rest of the "world" will work with the version of the package FOO
you modified, so either you stick to an old snapshot of all the packages
(i.e. "stuck in time") or you have to port your change to a newer
version of FOO (i.e. live on the bleeding edge).

If you push the precise-version-dependency argument to its logical
conclusion, packages should even refuse to work (unless you modify them,
that is) with your locally modified version of FOO because, well, they
haven't been tested against your version of the package, have they?
Their coders wouldn't want to receive bug reports about people using
their package with your modified FOO.


        Stefan

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

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Stefan Kangas <stefankangas <at> gmail.com>
Cc: Daniel Mendler <mail <at> daniel-mendler.de>,
 Philip Kaludercic <philipk <at> posteo.net>, 77075 <at> debbugs.gnu.org
Subject: Re: bug#77075: [PATCH] Prepare package.el to be published on GNU
 ELPA, [PATCH] Prepare package.el to be published on GNU ELPA
Date: Tue, 18 Mar 2025 23:17:21 -0400

> Not sure what you mean by that, but if you want me to explain why
> I think it erodes Free Software: in systems like Rust/Go/JS where
> dependencies tend to be very tight, it becomes a lot more difficult to
> maintain local changes to a piece of code,

Oh, and if you want to see this problem in real life, go check the
status of packaging Rust/Go/JS applications in GNU/Linux distributions.


        Stefan

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

From: Philip Kaludercic <philipk <at> posteo.net>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: Daniel Mendler <mail <at> daniel-mendler.de>,
 Stefan Kangas <stefankangas <at> gmail.com>, 77075 <at> debbugs.gnu.org
Subject: Re: bug#77075: [PATCH] Prepare package.el to be published on GNU
 ELPA, [PATCH] Prepare package.el to be published on GNU ELPA
Date: Wed, 19 Mar 2025 16:27:10 +0000

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

>>> I'm worried that our standard practice is being polluted by other
>>> systems where it's routine to force all users to constantly upgrade
>>> everything (which I believe ultimately erodes the freedoms offered by
>>> Free Software), so I think it's important that the packages over which
>>> we have some control preserve the tradition of being careful to keep
>>> dependencies no stricter than necessary.
>>
>> Could you perhaps briefly explain the philosophical argument?
>
> Not sure what you mean by that, but if you want me to explain why
> I think it erodes Free Software: in systems like Rust/Go/JS where
> dependencies tend to be very tight, it becomes a lot more difficult to
> maintain local changes to a piece of code, because pretty quickly none
> of the rest of the "world" will work with the version of the package FOO
> you modified, so either you stick to an old snapshot of all the packages
> (i.e. "stuck in time") or you have to port your change to a newer
> version of FOO (i.e. live on the bleeding edge).
>
> If you push the precise-version-dependency argument to its logical
> conclusion, packages should even refuse to work (unless you modify them,
> that is) with your locally modified version of FOO because, well, they
> haven't been tested against your version of the package, have they?
> Their coders wouldn't want to receive bug reports about people using
> their package with your modified FOO.

In that case I misunderstood what you are referring to, but I agree that
it is a relevant concern.  If you think it is worth it, I can check if
reducing the version of Compat is feasible, or if that would just
require the introduction of too many kludges.

>
>         Stefan

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

From: Daniel Mendler <mail <at> daniel-mendler.de>
To: Philip Kaludercic <philipk <at> posteo.net>
Cc: 77075 <at> debbugs.gnu.org, Stefan Monnier <monnier <at> iro.umontreal.ca>,
 Stefan Kangas <stefankangas <at> gmail.com>
Subject: Re: bug#77075: [PATCH] Prepare package.el to be published on GNU
 ELPA, [PATCH] Prepare package.el to be published on GNU ELPA
Date: Wed, 19 Mar 2025 18:01:54 +0100

Philip Kaludercic <philipk <at> posteo.net> writes:

> Stefan Monnier <monnier <at> iro.umontreal.ca> writes:
>
>>>> I'm worried that our standard practice is being polluted by other
>>>> systems where it's routine to force all users to constantly upgrade
>>>> everything (which I believe ultimately erodes the freedoms offered by
>>>> Free Software), so I think it's important that the packages over which
>>>> we have some control preserve the tradition of being careful to keep
>>>> dependencies no stricter than necessary.
>>>
>>> Could you perhaps briefly explain the philosophical argument?
>>
>> Not sure what you mean by that, but if you want me to explain why
>> I think it erodes Free Software: in systems like Rust/Go/JS where
>> dependencies tend to be very tight, it becomes a lot more difficult to
>> maintain local changes to a piece of code, because pretty quickly none
>> of the rest of the "world" will work with the version of the package FOO
>> you modified, so either you stick to an old snapshot of all the packages
>> (i.e. "stuck in time") or you have to port your change to a newer
>> version of FOO (i.e. live on the bleeding edge).
>>
>> If you push the precise-version-dependency argument to its logical
>> conclusion, packages should even refuse to work (unless you modify them,
>> that is) with your locally modified version of FOO because, well, they
>> haven't been tested against your version of the package, have they?
>> Their coders wouldn't want to receive bug reports about people using
>> their package with your modified FOO.
>
> In that case I misunderstood what you are referring to, but I agree that
> it is a relevant concern.  If you think it is worth it, I can check if
> reducing the version of Compat is feasible, or if that would just
> require the introduction of too many kludges.

We should not introduce kludges in order to reduce the version
requirements. As Stefan argues, it is best to require the version of a
dependency such that all necessary features are provided, but not
unnecessarily depend on newer versions "just because".

While I understand and share Stefan's arguments and concerns in general,
and the problems in other systems like Rust/Go/JS, I find it a bit
misplaced to bring them up in this particular case. We have made Compat
specifically to make it easier for package authors to support older
Emacs versions, which arguably increases freedom for the users.

Daniel

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

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Philip Kaludercic <philipk <at> posteo.net>
Cc: Daniel Mendler <mail <at> daniel-mendler.de>,
 Stefan Kangas <stefankangas <at> gmail.com>, 77075 <at> debbugs.gnu.org
Subject: Re: bug#77075: [PATCH] Prepare package.el to be published on GNU
 ELPA, [PATCH] Prepare package.el to be published on GNU ELPA
Date: Wed, 19 Mar 2025 16:31:39 -0400

> In that case I misunderstood what you are referring to, but I agree that
> it is a relevant concern.  If you think it is worth it, I can check if
> reducing the version of Compat is feasible, or if that would just
> require the introduction of too many kludges.

Again, I'm talking about changing only the `Package-Requires:`
header, not changing the code.
If the code uses a feature in a more recent version, then by all means,
do bump up the `Package-Requires:` accordingly.


        Stefan

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

From: Philip Kaludercic <philipk <at> posteo.net>
To: Stefan Kangas <stefankangas <at> gmail.com>
Cc: 77075 <at> debbugs.gnu.org, Stefan Monnier <monnier <at> iro.umontreal.ca>
Subject: Re: bug#77075: [PATCH] Prepare package.el to be published on GNU ELPA
Date: Mon, 24 Mar 2025 18:27:37 +0000

Stefan Kangas <stefankangas <at> gmail.com> writes:

> Philip Kaludercic <philipk <at> posteo.net> writes:
>
>> As far as I am aware, the main objection to this idea is that this might
>> introduce instability that is difficult to fix (If `package-delete'
>> doesn't work, then it isn't obvious how to uninstall the newer
>> package.el).  Are there any other points we should discuss?
>
> Can you summarize what is our reply to that?  Do we have a better
> workaround than `rm -rf ~/.emacs.d/elpa`?

My idea was to have a specialised, specialised command to uninstall all
ELPA versions of package.el.

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

From: Philip Kaludercic <philipk <at> posteo.net>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: Daniel Mendler <mail <at> daniel-mendler.de>,
 Stefan Kangas <stefankangas <at> gmail.com>, 77075 <at> debbugs.gnu.org
Subject: Re: bug#77075: [PATCH] Prepare package.el to be published on GNU
 ELPA, [PATCH] Prepare package.el to be published on GNU ELPA
Date: Mon, 24 Mar 2025 19:05:01 +0000

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

>> In that case I misunderstood what you are referring to, but I agree that
>> it is a relevant concern.  If you think it is worth it, I can check if
>> reducing the version of Compat is feasible, or if that would just
>> require the introduction of too many kludges.
>
> Again, I'm talking about changing only the `Package-Requires:`
> header, not changing the code.
> If the code uses a feature in a more recent version, then by all means,
> do bump up the `Package-Requires:` accordingly.

At least according to package-lint, we appear not to be using any
functionality added after Emacs 28.

>
>         Stefan

Previous Next

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