[Feature]: Install from ELPA tarballs

[p00f]

Feature Description

Currently if I want to install a newer eglot/eldoc/erc than the one included in the emacs release, I have to remove :ensure nil from the use-package call, but then elpaca downloads all of emacs.
I just did an elpaca-update-all now and 5 processes are pulling the entire emacs repository:

On the other hand, the tarball at https://elpa.gnu.org/packages/eglot.html is just 310KB

Confirmation

• The feature I'm proposing does not already exist in Elpaca

[p00f]

[progfolio]

Thanks for the suggestion.

There are a few ways we could mitigate disk usage here.

First, if you find upgrading more than a handful of built-in packages, it may be time to upgrade Emacs, if possible.
That's generally easier to deal with. I understand that's not always a desirable option.

Second, elpaca-menu-elpa.el could be taught to use a sparse checkout of the Emacs repository. That could cut disk usage down (~245MB to ~136MB from a quick test I did with eglot).

Third, we can teach Elpaca how to install directly from tarballs, as you mention. That would involve generalizing the commands which operate on packages. The recipe format would need a way to express that, too. I've thought about this before, but haven't worked out a good design yet. I'll experiment some more.

Any ideas, suggestions, etc are always welcome. Thanks.

[p00f]

Second, elpaca-menu-elpa.el could be taught to use a sparse checkout of the Emacs repository. That could cut disk usage down (~245MB to ~136MB from a quick test I did with eglot).

It's not really about disk usage for me, it's just that it takes a while to install/update

[p00f]

First, if you find upgrading more than a handful of built-in packages, it may be time to upgrade Emacs, if possible.

I'm not sure about this: emacs 29.3 was released on 24 March, with built-in eglot=1.12. eglot 1.17 on ELPA says it was released on 31st March. I don't think they bumped 5 minor versions in a week

[progfolio]

I'm not sure about this: emacs 29.3 was released on 24 March, with built-in eglot=1.12

29.3 was a security bug fix release.
So the version of eglot bundled with Emacs is likely the same as it was in 29.2 (released 1/18/2024). I don't think the Emacs release date is necessarily a good measure of when a core package was last updated.

eglot 1.17 on ELPA says it was released on 31st March. I don't think they bumped 5 minor versions in a week

If I recall correctly, "core" packages are treated differently than other GNU ELPA packages.
The ELPA release dates don't seem to line up with the commit dates which bump the package Version header:

emacs [master]$ git log  -3 --oneline --format='%h %cd %s' --grep="bump to" -- lisp/progmodes/eglot.el 

b014bca833a Thu Jan 25 12:20:27 2024 +0000 Eglot: bump to 1.17
c5a4366b3f3 Wed Dec 27 08:02:20 2023 -0600 Eglot: bump to 1.16
30892cbd330 Sat Apr 29 23:31:29 2023 +0100 Eglot: bump to 1.15

However, if you read the NEWS section on the ELPA page, the dates seem to match the commits which bumped the Version. It's yet another confusing wrinkle in the ELPA machinery.

It's not really about disk usage for me, it's just that it takes a while to install/update

Understood. I think a sparse checkout may help with subsequent fetches as well, but I'll have to look into that more.

[p00f]

It seems to grow a lot - there's no way there's 1.5+GB of code churn