Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Feature]: Install from ELPA tarballs #300

Open
1 task done
p00f opened this issue Apr 28, 2024 · 6 comments
Open
1 task done

[Feature]: Install from ELPA tarballs #300

p00f opened this issue Apr 28, 2024 · 6 comments
Labels
enhancement New feature or request

Comments

@p00f
Copy link

p00f commented Apr 28, 2024

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:

20240428_12h26m52s_grim

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 p00f added the enhancement New feature or request label Apr 28, 2024
@p00f
Copy link
Author

p00f commented Apr 28, 2024

20240428_16h52m20s_grim

@progfolio
Copy link
Owner

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
Copy link
Author

p00f commented Apr 29, 2024

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
Copy link
Author

p00f commented Apr 29, 2024

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
Copy link
Owner

progfolio commented Apr 29, 2024

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
Copy link
Author

p00f commented Jul 13, 2024

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants