eglot's version on melpa no longer updates, causing an issue for nixpkgs

[jian-lin]

Eglot's github repo no longer updates.

As a result, its version on melpa stays at 20221020.1010, which is older than the one on GNU ELPA or GNU-devel ELPA.

This causes an issue for nixpkgs: by default, users will not get newer version of eglot than 20221020.1010, because nixpkgs prefers packages in melpa over GNU ELPA1.

I would like to hear your ideas of solving this issue. The one I can think of is removing eglot from melpa.

EDIT: Of course, adding an exception for eglot to prefer elpa over melpa is also possible in the downstream nixpkgs.

@joaotavora

[tarsius]

Removing it from Melpa seems like the most reasonable and simplest solution.

[jian-lin]

Thanks!

[joaotavora]

That's not unreasonable indeed, though I was just about to solve this. Sorry for the mammoth delay in attending to this.

[joaotavora]

(I don't think nixpkgs should be preferring melpa over elpa, btw)

[tarsius]

I can of course revert this, but it seems to me that we don't really need it on Melpa anyway.

One argument for keeping it on Melpa is that the version on GNU ELPA isn't the latest snapshot and most users don't add GNU-devel ELPA to their list of ELPAs to use. Whether that is a problem depends on how often you intend to create releases, I suppose.

[joaotavora]

I can of course revert this, but it seems to me that we don't really need it on Melpa anyway.

No, don't for now.

One argument for keeping it on Melpa is that the version on GNU ELPA isn't the latest snapshot and most users don't add GNU-devel ELPA to their list of ELPAs to use. Whether that is a problem depends on how often you intend to create releases, I suppose.

Yep. Well, more or less. Eglot isn't updated regularly on GitHub anymore, it's now in Emacs. I tend to only update eglot.el in the GitHub repo for every release or if I need to test using the GitHub CI.

But I do know that many users used to rely on Melpa to get convenient access to the bleeding edge. I would not mind that -- if it's possible to do. The lisp/progmodes/eglot.el file now lives the master branch of Emacs.git (savannah, but also mirrored here in Github) .

[jian-lin]

(I don't think nixpkgs should be preferring melpa over elpa, btw)

Would you mind explain it a bit? Maybe the Emacs maintainer of nixpkgs (@adisbladis) is interested.

[joaotavora]

Would you mind explain it a bit? Maybe the Emacs maintainer of nixpkgs (@adisbladis) is interested.

Just a knee-jerk opinion, maybe. But if a package in is GNU ELPA, which is a distribution outlet closer to Emacs's development, and thus more likely to be working correctly, be preferred? Especially if the date is newer.

Anyway, I'm sure nixpkgs maintainer had some reason for doing that.

[adisbladis]

Would you mind explain it a bit? Maybe the Emacs maintainer of nixpkgs (@adisbladis) is interested.

This priority order predates my involvement in nixpkgs so I can only guess as to what the motivations were.

Generally speaking MELPA is way more up to date than other package archives so it makes sense that it takes precedence.

In any case this is something that is user overridable and the defaults have been around for a long time so I'm very reluctant to touch it. It has worked for us so far.

[akirak]

Generally speaking MELPA is way more up to date than other package archives so it makes sense that it takes precedence.

This should be true because MELPA builds packages from latest source. Package on GNU ELPA are auto-synced by default now, while some packages are manually synced for reasons.

But if a package in is GNU ELPA, which is a distribution outlet closer to Emacs's development, and thus more likely to be working correctly, be preferred? Especially if the date is newer.

GNU ELPA hosts core packages (which are also shipped with Emacs) and external packages. While the claim often applies to core packages, auto-synced external packages should be basically the same as equivalents (if any) on MELPA.

A weird situation is that a package can exist on both GNU Core ELPA (developed by the Emacs maintainers) and MELPA. I think the simplest solution to this problem is to simply remove the package from MELPA, as is done for eglot.

As a side note, my twist.nix properly handles built-in packages, so the user can avoid using an outdated version of package which is shipped as part of Emacs. It's still in alpha state (mostly due to lack of documentation and supporting resources) though.

[tarsius]

@akirak Do you know how elpa-admin handles snapshots of core packages? I.e., do these packages get regular updates on GNU-devel ELPA, like packages maintained in external repositories? I would assume so, but if not, then that would change the picture a lot.

A weird situation is that a package can exist on both GNU Core ELPA (developed by the Emacs maintainers) and MELPA. I think the simplest solution to this problem is to simply remove the package from MELPA, as is done for eglot.

I tend to agree, but for now the Melpa policy is to leave the decision up to the package maintainer. (Unless we become aware of issues, such as in this case, where our snapshot had begun to lag behind a lot.)

One reason is that, like Melpa, [Non]GNU-devel ELPA are not used unless the user explicitly adds them. They have already added Melpa, expecting snapshot releases to keep coming, but maybe without realizing that they would also need to add [Non]GNU-devel ELPA to ensure that.

Generally speaking, things are much more in flux right now, and it will take time to sort everything out. So if nothing else, it is good discussions like this come up occasionally, giving more people a change to become aware of issues that are not resolved yet, and maybe come up with solutions we haven't thought of yet.

@adisbladis

Generally speaking MELPA is way more up to date than other package archives so it makes sense that it takes precedence.

It (that is Melpa "unstable") is more up-to-date than GNU ELPA and NonGNU ELPA (which are more like Melpa stable), but GNU-devel ELPA and NonGNU-devel ELPA also exist. Like regular Melpa they distribute snapshots.

In any case this is something that is user overridable and the defaults have been around for a long time so I'm very reluctant to touch it. It has worked for us so far.

The default dates back to before the -devel variants were created, I assume. I think the time has come to consider preferring GNU-devel ELPA over Melpa. Maybe even NonGNU-devel over Melpa as well. There is no rush at all, but I expect this change is going to be made eventually. Might as well start looking into what that entails now.

[joaotavora]

A weird situation is that a package can exist on both GNU Core ELPA (developed by the Emacs maintainers) and MELPA. I think the simplest solution to this problem is to simply remove the package from MELPA, as is done for eglot.

That's not dramatic, but slightly unfortunate. For example Eglot hasn't had a release in about two months (one is around the corner, though) but during this time it has seen a fair amount of work. The traditional way meloa treated my packages was too build them and distribute them from the bleeding edge. Why can't it do that with :core packages?

[joaotavora]

Just hearing about GNU-devell ELPA now, so maybe that's a nice solution to direct people to. Will check it out (where?)

[tarsius]

(where?)

I always have to use google do locate it. (It might be a good idea for non-devel to link to devel and vice versa, like is done for Melpa "unstable"/stable. 😀

[akirak]

@tarsius I have heard of GNU-devel ELPA but didn't understand how it is useful. Thank you for the pointer. Will check it out soon.

[tarsius]

The traditional way meloa treated my packages was too build them and distribute them from the bleeding edge. Why can't it do that with :core packages?

Packages that are maintained as part of a large repository that contains much more than just the package in question are a problem. The whole repository has to fetched and checked out. We cannot use the git features that would allow us to only use parts of it. One reason for that is that we are interested in the latest tag, which might not be available if we only fetch the last N commits. There are probably other issues, that I cannot think of right now.

We are trying to get upstreams to maintain their elisp in independent repositories. See #5361.

As more and more "core" packages are created, we would have to check out more one more copies of emacs.git. Of course we could implement a special case for emacs.git, and forever maintain that, but its just more work, that we could easily avoid. (And it likely would be me who would have to implement that (I am the maintainer of package-build.el). For Melpa, and then again for the Emacsmirror. And I really don't feel like doing that.)

That's another reason why I hope we will instead settle on leaving it to GNU[-devel] ELPA to deal with "core" packages. There might be benefit to keeping these packages in Melpa, whether real or assumed, but for me the only consequence would be a lot of additional work. (I don't use any of these archives or even just package.el myself, but I maintain a lot of related stuff for the benefit of those who do.)