Question about the state of package managers

A year or two ago, straight.el was probably the most recommended package manager for GNU Emacs. As I’ve revisited my configuration today, I noticed that there are a few recent package managers (namely, leaf and elpaca) which are new to - at least - me and (at least elpaca) want to be straight.el’s “successor”. Is there any write-up about the state of GNU Emacs package management in 2022? Straight.el *works for me* (and I need its custom build features for two packages), but I don’t want to rely on *deprecated* packages for too long.

`leaf` is a replacement for `use-package`. It's a configuration manager, not a package manager. Like use-package, it supports package managers like package.el and straight.el. I haven't switched to it because use-package works for me, but it's probably pretty cool. I've briefly experimented with Elpaca and it certainly _can_ replace Straight. The maintainer of both is u/nv-elisp, they probably have a better take about which to use.

I like `leaf` because it is more syntactically consistent, and doesn't emit a require unless you tell it to. Not sure if it's still the case but `use-package` would conditionally emit a require based on if you used `defer`, `bind`, etc.

[deleted]

You're correct in making the distinction between a configuration macro and a package manager. > I've briefly experimented with Elpaca and it certainly can replace Straight. The maintainer of both is u/nv-elisp, they probably have a better take about which to use. I am actively developing [Elpaca](https://github.com/progfolio/elpaca) and have been using it myself for the past year or so. I would encourage others to try it out as it is an improvement over straight.el. It is simpler by design, has an improved UI, and does much of its work asynchronously without blocking the main Emacs thread. This leads to much faster package installation. A clean install of 116 packages (which includes building several system binaries for mu4e, pdf-tools, etc) takes roughly 115-120 seconds on my laptop. I should probably release a video to actively promote the fact that Elpaca is in a usable state, too. It does require some rethinking of one's init file due to the asynchronous nature of package installation/activation, but I've provided a macro, `elpaca-use-package`, specifically for use-package users which is a drop in replacement for the most part. I am still maintaining straight.el alongside the original author, u/raxod502 as well. Long term, I'd like to drop support for straight.el in favor of Elpaca. That doesn't mean straight will go away, I just wouldn't be devoting time to supporting it at that point.

Can you be more specific about `elpaca-use-package` being a drop-in replacement "for the most part"? What does it not do? Also, what method do you use for package discovery?

> Can you be more specific about elpaca-use-package being a drop-in replacement "for the most part"? What does it not do? (defmacro elpaca-use-package (order &rest body) "Execute BODY in `use-package' declaration after ORDER is finished. If the :disabled keyword is present in body, the package is completely ignored. This happens regardless of the value associated with :disabled. The expansion is a string indicating the package has been disabled." (declare (indent 1)) (if (memq :disabled body) (format "%S :disabled by elpaca-use-package" order) `(elpaca ,order (use-package ,(elpaca--first order) ,@body)))) It wraps a use-package declaration so that it is executed after a queue of asynchronous package installation/building is complete. So all of the usual use-package features are supported (there may be an edge case when calls are nested, but I wouldn't recommend that with vanilla use-package declarations either). I meant "for the most part" in that one may have to alter some declarations if they are using the `:striaght` use-package keyword. I'm sure there are other corner cases where alterations other than `s/use-package/elapca-use-package/` would be necessary. > what method do you use for package discovery? Elpaca works off a similar concept to straight's recipe repositories. The [readme](https://github.com/progfolio/elpaca#basic-concepts) explains how package recipes are derived. From a user perspective, the `elpaca-manager` command allows one to search all known recipes in a UI that is similar, but more flexible than, package.el's `list-packages` interface. Elpaca is also designed to be easily extended in this regard, too. I often review pull requests for packages submitted to MELPA. Here is an example implementation of an Elpaca "recipe menu" for such pull requests: [melpulls](https://github.com/progfolio/melpulls) II hope that answers your question. I'll have to make a demo video of all of this soon, as I think it will be a better demonstration than me writing about it.

I'll definitely keep an eye on elpaca!

Emacs 29 may come with support for installing packages from version control. I'm excited to get rid of all the above tbh.

While I welcome improvements to package.el, I don't think the recent work will be enough to replace alternative package managers yet.

I see u/nv-elisp is in this thread. :) Thanks for all you do! I've been using Elpaca for the past… er… three-ish months? It's made my startup time drop nicely, and has some definite improvements over straight.el, but it still feels very much alpha-like and I've had stuff break in ways that have required some tweaking. (Usually from packages just doing really weird stuff to get installed. Looking at you auctex.) straight.el is solid as all get-out. I recommend using that if you want something reliable and something that requires little-to-no twiddling. If, on the other hand, you're someone who builds Emacs from source and enjoys trying bleeding-edge software and is comfortable breaking stuff and submitting bug reports (of which I've done several with Elpaca) then use Elpaca!

In what way? I haven't tried the branch yet but it sounded like an improvement over straight.el

> Usually from packages just doing really weird stuff to get installed. Looking at you auctex yes, that package is the cause of quite a few bug reports/support requests for straight.el as well. To your point, Elpaca is far from "finished", but it's at the point where it would benefit from more people testing it. I appreciate you taking the time to test it. > Thanks for all you do! Thank you.

Radon did a nice job of comparing striaght.el to package.el here: https://github.com/radian-software/straight.el#advantages-of-straightel Many of the points there are covered in Elpaca as well (the main difference being that I'm taking a slightly different approach to lockfiles). While I appreciate the work being done on package.el, it does not cover all the functionality offered by either package. What package.el features do you see as an improvement over straight.el?

I'm excited to use elpaca! I'll be awaiting the merge of the feat/use-package-support branch so I don't have to adapt my config too much :)

straight.el seems to promote an all-or-nothing approach to installing from git. I only want to install from source as a last resort if it's not available from elpa or melpa.

> and does much of its work asynchronously without blocking the main Emacs thread. This is potentially a stupid question, but does that mean that I can start using Emacs and editing stuff *while* elpaca is installing and configuring packages? I don't *exactly* remember how it works with straight, but I thought you could theoretically get some commands in when straight was "in between" installing packages or whatever. Is that not correct? Does straight hog the whole process until its totally done? Either way, I'd *love* for my packages to download and install concurrently, but I also kind of want my init.el to be "finished" before I'm able to start doing work because I don't want to be able to start hitting shortcuts or executing commands that aren't ready yet. That might be weird of me, but I *rather* an app not let me do stuff until it's ready. If Emacs could have a big, honkin', "loading" spinner while it's processing init.el, I actually think that would be good... /tangent Anyway, thank you for your work in this area. I've been using straight for quite some time and I'm going to try out elpaca as soon as I get some cycles to devote to tinkering with my config.

> does that mean that I can start using Emacs and editing stuff while elpaca is installing and configuring packages? Yes, but, more practically, it means that if a process is blocked for some reason you don't have to sit there wondering if something went wrong or it's just taking a long time to complete. You can recover from a failed installation of a package without restarting Emacs. Straight.el is opaque in this way. There's also the case of installing packages to try them out after Emacs has been initialized. You're free to continue what you were doing while waiting for packages to install/build. Typically, packages should build relatively fast, but there are many factors that determine how fast. There's no need to block in this case, though. > I thought you could theoretically get some commands in when straight was "in between" installing packages or whatever. Is that not correct? Does straight hog the whole process until its totally done? Straight.el's external process calls are all synchronous and blocking. There is some user-contributed code which allows fetching all packages asynchronously, but that is not integrated into straight.el proper and only covers one operation. > If Emacs could have a big, honkin', "loading" spinner while it's processing init.el, I actually think that would be good... Far from good when you don't know *why* it's being blocked. Especially paired with the fact that straight will delete everything it's done up to the point where it has hung in some cases so that relaunching Emacs just hangs again. Elpaca is much better in this regard. When packages are being installed you get a detailed, live log view of the output of each subprocess involved in building the package. You can also see the status of a package, which allows you to tell if it is blocked by something (a subprocess asking for input- which you can send, a dependency, waiting on the network, etc) or if the package order has failed for some reason. For example, I've had packages fail to install due to a network hiccup. With straight, I'd not know which package failed or why, restart Emacs and wait for all my packages to reinstall again, hoping for the best. In Elpaca, I can see why the package failed, and attempt to reinstall it with a couple of key presses. > Anyway, thank you for your work in this area. I've been using straight for quite some time and I'm going to try out elpaca as soon as I get some cycles to devote to tinkering with my config. Thanks for checking both out. I hope you find them useful.

Why do you prefer a tarball from M/ELPA over a source repository? The two main arguments I've heard for this are: - Disk space - Security To address the first, Elpaca and straight default to shallow clones, but the cost in storage we're talking about for several hundred elisp repositories is negligible for most users. As far as security goes, I would say GNU ELPA, NonGNU-ELPA, and MELPA offer little. MELPA provides an initial package review, which is moot once the package is accepted (the author is free to update as they please without further review). On the GNU side, the possibility for ongoing review is dependent on volunteer time. Leaning on either too heavily for peace of mind is a mistake in my opinion. Are there any other reasons you'd prefer a distributed tarball to the source repository?

Being able to downgrade/switch branches is such a huge advantage; I’m not sure how I’d live without that now. I’ve had to switch to branches of packages like mu4e-views to get compatibility with the latest versions of mu, etc. After tasting that power, I don’t think I’ll ever be able to go back to package.el or any non-git based package manager.

> Elpaca and straight default to shallow clones, but the cost in storage we're talking about for several hundred elisp repositories is negligible for most users. I disagree. The update process doesn't shallow clone, it pulls. So beyond the ~200KB initial space, it will grow over time. On top of that straight.el doesn't respect .elpaignore so things like demo images or tests will be downloaded. You didn't mention speed and stability but those are also important to me. Edit: I just shallow cloned avy. The .git directory is larger than the rest of the files combined.

Amazing work so far. I really like some of the improvements elpaca provides over straight (and others), such as the support of `:tag` and `:ref` directly in the recipe. >I meant "for the most part" in that one may have to alter some declarations if they are using the `:striaght` use-package keyword. I'm sure there are other corner cases where alterations other than `s/use-package/elapca-use-package/` would be necessary. Is there a reason you decided against providing a keyword like `:elpaca` to the regular use-package macro, similar to straight (or quelpa and el-get with the help of third-party packages)? I'd much prefer it that way to be honest, rather than replacing all my use-package invocations.

You're probably correct when it comes to speed of installation for straight.el vs package.el. One of the main improvements of Elpaca is its speed by leveraging asynchronicity as much as possible. Elpaca is plenty fast for my needs, but I'll run some tests against package.el out of curiosity. It's not exactly a one-to-one comparison, though, seeing as they take different approaches to building packages. As far as stability is concerned, Straight and Elpaca allow users to define "stable" for themselves via lock files. Elpaca also allows pinning packages to particular git references/commits. The inflexibility of package.el in this regard is part of what originally got me interested in Straight. I appreciate that you may prioritize storage space over some of the features straight and Elpaca provide, but I don't think the majority of users find a few extra MB's too high a price. I'll keep it in mind, though. There are definitely ways to reduce the storage cost of repositories even when pulling updates. Thanks for your input.

> Amazing work so far. I really like some of the improvements elpaca provides over straight (and others), such as the support of :tag and :ref directly in the recipe. Thank you. > Is there a reason you decided against providing a keyword like :elpaca to the regular use-package macro, similar to straight (or quelpa and el-get with the help of third-party packages)? Yes. Elpaca installs packages asynchronously. You can see a more thorough explanation here: https://github.com/progfolio/elpaca/issues/7 The wrapper macro is the simplest solution to the problem described there. There is a branch where I've implemented an `:elpaca` keyword for use-package. I'm still experimenting to see if I can come up with a cleaner solution than what I already have, though. > I'd much prefer it that way to be honest, rather than replacing all my use-package invocations. I understand. Though, I will say it didn't take much for me to convert my init. I've more than made up that time just in installation speed alone. I'll keep experimenting to find the easiest method to transition existing init files which make use of configuration macros.

Thanks for the answer and link to the ticket. I'll be watching elpaca's progress closely and give it a shot once I have some time.

If you like the git based workflow you might try borg plus epkg. I have two machines one for work and at home updating between each is easy. Just do a git pull and run make. To update packages you also use git pull. A plus for me is that I can contribute to other packages easier or test new features.

There's also borg which does the same. I'm not sure how good that feature will be, I found vc always quite spartanic.

I'm also looking forward to that support in package.el. The other package managers do a lot more, but for my use, the only thing lacking in package.el is the ability to easily install packages from online git repositories.