Request: Remove package from melpa

[benjaminor]

Given this package now lives in core (and has a more current version on elpa), do you think it would be appropriate to remove use-package from melpa? AFAIK the policy of melpa is to keep the package as long as the maintainer does not request to remove it himself.

The reason I am asking is in nixpkgs, melpa packages are preferred over elpa packages, which means one has to manually adjust the source of use-package to get the current version. A rather benign reason, but I still think as use-package now lives on elpa and is not updated anymore in melpa, it should be removed from there.

[8573]

in nixpkgs, melpa packages are preferred over elpa packages

I have no opinion on whether the package's having been promoted means that it ought to be removed from MELPA, but (writing this from NixOS) this sounds unfortunate. Could nixpkgs change that?

[benjaminor]

In eglot's case, its package was removed from melpa (melpa/melpa#8420) after it was moved to core emacs. Regarding nixpkgs, I'll think about opening an issue to discuss package precedence, but I think they are rather reluctant to change the current code, see melpa/melpa#8420 (comment).

[skangas]

I think it makes sense to remove use-package from MELPA now that it is a core package (and on GNU ELPA), indeed.

@jwiegley What do you think? Should I go ahead and put in a request for its removal?

[jwiegley]

What about users of older versions of Emacs? Shouldn’t we wait until a few versions from now to remove it? John

…

On Sat, Aug 5, 2023, at 8:29 AM, Stefan Kangas wrote: I think it makes sense to remove use-package from MELPA now that it is a core package (and on GNU ELPA), indeed. @jwiegley <https://github.com/jwiegley> What do you think? Should I go ahead and put in a request for its removal? — Reply to this email directly, view it on GitHub <#1055 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAACCDG62SSM7O52JMR7A4LXTZREVANCNFSM6AAAAAAY3G2FKQ>. You are receiving this because you were mentioned.Message ID: ***@***.***>

[skangas]

What about users of older versions of Emacs? Shouldn’t we wait until a few versions from now to remove it?

Users of older versions of Emacs can still use the version on GNU ELPA, so I don't believe that will be an issue.

One issue that we will have is that people having the MELPA package 20230426.2324 installed will not automatically get upgraded to 2.4.5. Or indeed to any release with a major version below 20230426. :-( But that was inevitable once we decided to make it into a core package, given the MELPA versioning scheme. The MELPA removal will not affect this issue, I think, (but it might encourage people to uninstall the MELPA package in favor of the built-in or GNU ELPA one).

[jwiegley]

>>>> "SK" == Stefan Kangas ***@***.***> writes:

SK> Users of older versions of Emacs can still use the version on GNU ELPA, so SK> I don't believe that will be an issue. SK> One issue that we will have is that people having the MELPA package SK> 20230426.2324 installed will not automatically get upgraded to 2.4.5. Or SK> indeed to any release with a major version below 20230426. :-( But that SK> was inevitable once we decided to make it into a core package, given the SK> MELPA versioning scheme. The MELPA removal will not affect this issue, I SK> think, (but it might encourage people to uninstall the MELPA package in SK> favor of the built-in or GNU ELPA one). In that case, it sounds like removing from MELPA sounds right.

…

-- John Wiegley GPG fingerprint = 4710 CF98 AF9B 327B B80F http://newartisans.com 60E1 46C4 BD1A 7AC1 4BA2

[8573]

One issue that we will have is that people having the MELPA package 20230426.2324 installed will not automatically get upgraded to 2.4.5.

Maybe use-package could have a final release to MELPA that advises users to replace it with the GNU ELPA version, or even replaces itself?

[skangas]

Maybe use-package could have a final release to MELPA that advises users to replace it with the GNU ELPA version, or even replaces itself?

Good point. If it could replace itself, that would be great of course. Do you have any ideas for how we could do that?

Otherwise, perhaps warning about it on load would be enough. Maybe that is also reason to leave the MELPA package around for a while longer - like a year or two? I'm not sure.

[jian-lin]

Given this package now lives in core (and has a more current version on elpa)

It is not true now: MELPA version is 20230426.23241 which is newer than both ELPA2 and ELPA-devel3.

To my surprise, the code on github is not the same as the one in Emacs core. For example, this breaking change4 is only on github. What is the policy for the divergence of code?