Strategies to manage Emacs packages

What is your strategy to manage Emacs packages? Only with \`package.el\`? Git submodules? \`straight.el\`? I was searching some ways that I could do it and a find so many things that I could do to reach similar results that I'm curious about the possibilities behind it. How do you do it?

`straight.el` to pull and resolve recipes, and `use-package` to load and configure them. My init.el requires another file, `mitch-packages.el` which is about 300 lines long. I put built-in packages at the top of the file (ex: eshell, tramp, org), then important packages that affect everything (ex: general, evil, vertico) then more specialized and one-off features like minimap, extra languages, and colorscheme. This way, I can make my emacs.d (actually .config/emacs but whatever) a standalone git repository, then clone it or treat it as a submodule to my dotfiles repo (which is managed as a bare repo with $HOME as the work tree). Whenever I deploy to a new machine or delete+re-clone the repo, straight.el bootstraps itself, loads its init file, and downloads everything as spec'd in my packages file the first time emacs starts up. My packages file [here](https://git.mitchmarq42.xyz/mitch/emacs.d/src/branch/main/lisp/mitch-packages.el). I've also been experimenting with [elpaca](https://github.com/progfolio/elpaca) recently, but I don't know if it's quite right for me yet. It does seem to be very fast though. EDIT: looks like my packages file is closer to 800 lines. Well, I use most of them so that's probably okay for now.

Package.el. it's very featureful, is built-in, and provides great package discoverability through the `list-packages` command. If I want to install a package that's not in (M)ELPA, or some package I've been working on, I use `package-install-file`. This copies it to the elpa directory and sets up autoloads and the load-path, just like any other package. Very nice.

I chose an operating system which includes Emacs *and* a large selection of packages, so I don't have to worry about it. The packages are part of the system; the ones I select get installed and updated along with the rest of the system (libraries, shell, compiler, browser, etc., and of course, Emacs itself) and are available to all users, like the rest of the system. No fuss, no muss.

I am currently using straight.el but I hope to replace it with package.el with Philip's recent work on vc integration.

Nix installs all my emacs packages for me

I use package.el + use-package, but for several packages that not in melpa I use chezmoi dotfiles manager to pull them from different git repos. My config is [here](https://github.com/Crandel/home/tree/master/.config/emacs)

[deleted]

I use a combination of package.el and [borg](https://github.com/emacscollective/borg)

package.el. [Mine is slightly hacked](https://github.com/amno1/.emacs.d/blob/main/lisp/package.el), so I can use git repos on my local disk (via symlinks) for packages I would like to hack on myself. But, in its everyday function, just package.el.

package.el (via `:ensure`) + quelpa (`:quelpa`)

I use `el-get` for installing external sources. It's not talked about much any more, but it had all the features I required at the time I started using it, and that's still true today.

Dooms package manager! (Which is a declarative front end to straight)

`package` plus `use-package`. I see lots of posts extolling the virtues of `straight` if you are developing or contributing to packages but I also see way more posts about `straight` problems than I do `package` problems. When I am hacking on a package, I simply use the `:load-path` directive of `use-package` to point emacs to the right place.

Sounds interesting. Any pointers on how I can learn more?

I'm using `straight` because there was one alternate version of a package I wanted to use instead of the standard melpa version. I use `use-package` because that's what most others use for organizing `init.el` and I often copy configuration code from the web. I don't really understand either of them, but they seem to work!

Actually, use-package uses package.el :p

Builtin package.el. Some users mentioned `use-package`. That is just calling package in a fancy way. Straight may give you some fine grained control since it uses Git repos instead of just packages. IDK, MELPA pulls from Git repos already, so if I find a bug on a version, I just go to GitHub and talk with the devs. Once the version is ready or the buggy change reverted, it gets to MELPA again and I just update. Version control is already backing MELPA somehow, I don’t know how much can I benefit of having a Git repo of every package I want to use. Almost every package manager just handles tarballs with snapshots from versioned repos.

I use https://github.com/progfolio/elpaca. It's a successor to straight.el I'm working on.

Let me know if you run into any bugs or design issues with Elpaca. I'm still working things out, so feedback is nice to hear.

Not always. It could use straight.el too

One thing that would be awesome to have is a use-package keyword, like `:straight` or `:quelpa`. Not sure how possible that is, and between `elpaca-use-package` and your `use-feature` macro it may not be necessary. No actual bugs so far, just silly me making assumptions about the order that things load in. I'll post an issue or PR if I find anything gnarly. I do have a life at the moment though, so it may be a few weeks. Thanks for also maintaining straight!

> a use-package keyword I've implemented an `:elpaca` use-package keyword, just have to work out a few kinks before I merge it. It will actually respect use-package's conditional keywords, too (:if, :when, :unless). > between elpaca-use-package and your use-feature macro it may not be necessary. These do work fine for now, but I'd like to come up with something more flexible so that users of other configuration macros (leaf, setup.el, etc) can benefit as well. > No actual bugs so far, just silly me making assumptions about the order that things load in. I'll post an issue or PR if I find anything gnarly. I do have a life at the moment though, so it may be a few weeks. Glad to hear all of that. Thanks for testing things out. > Thanks for also maintaining straight! Thank you.

Check amodernist.com

> amodernist.com Thanks. For others who might be interested, here is a direct link: http://amodernist.com/texts/package-vc.html

Yeah, well… is straight that uses use-package IMO. Use package uses just package.el, nothing more, but it’s ensure mechanism is overridden by straight to call itself instead. If you think this is some use-package capability, you may need to redefine “capability” a bit :p

I don't care about implementation. I just want to explicitly say, I'm not using straight.el

100% borg. It's more trouble in many ways than package.el or straight.el but it really just makes emacs feel like emacs to me to be able to go in and edit any package I use and have 0 problems with then taking those changes and opening a PR upstream or starting your own fork or whatever you want with them.