Updating My Custom Emacs Setup - Part One: Upgrading Packages

I've previously written about how it is viable to use a custom Emacs setup, but I didn't go too far into the details about what it's like to actually take that route. In this, the first post in a series on updating my custom Emacs setup, I'll talk about my workflow for upgrading packages to newer versions.

→ Why Update?

A wise man once told me, "never update anything". Indeed, why update anything in my Emacs setup at all? If things work just fine as-is, can't I just not update and chug along? Yeah I suppose I definitely could. After I've initially installed something, as long as I never delete it I'll have it on my computer. Every time I start Emacs, it will start the same way and run the same code. No problem, right?

Despite the relative security of never updating, I still feel compelled to grab updates for various packages. I don't do it often, but a recent Flycheck release prompted me to review and update some stuff. So I guess my answer to the "why" is: I want the new goodies, but also if there's a problem I can roll back with relative ease, so why not.

→ Trying Out An Update

So, I've decided I want to update some Emacs packages. What do I do? One of the big reasons I use straight.el is for how it leverages version control so that you can have a lockfile for all of your package versions. When you install something, it goes into a specific directory where package source repositories live and the version is registered in a lockfile. On my system, packages live at $HOME/.emacs.d/straight/repos.

First thing's first: I open up a terminal and cd to that directory, then I see what all is there. Several big name packages stand out, so one at a time I:

• cd into the repo directory for the package I want to update (e.g. cd ctrlf)
• Do a git pull
• Look at git log to try and get an idea of what sort of changes have happened

Most of the time, I'd be done at this point. There's always the possibility to check out a specific revision, but I usually go with whatever the latest code is.

It's important to note that sometimes non-Elisp changes happen that are outside the control of the Emacs package ecosystem. A good example of this is when python-language-server was deprecated, and python-lsp-server became the new defacto. This is something one could easily miss while doing code pulls on package repos.

With selected packages now updated, I'll then start a new (non-daemon) instance of Emacs and see how things are. At this point I'll try out modes that I know were updated to make sure they work as expected.

→ From Within Emacs

Naturally, there's no need to leave Emacs for this process. One can simply issue M-x straight-pull-package RET (or straight-pull-package-and-deps) and then specify which package should be updated.

→ Saving Updates

If everything looks good, I'll update the lock file with M-x straight-freeze-versions RET. The final step is to review the updated lockfile via Magit and commit if everything is satisfactory. It's not the most interesting diff you'll ever see, various commit shas will have been changed, but it does give you a nice high level overview of what's changed.

Okay, that's it. Expecting more? I was too but that's really the entire workflow for updating.

→ Reverting Updates

If for whatever reason you want to revert a package (and the lockfile hasn't been updated yet), all package versions can be restored to the versions specified in the lockfile with M-x straight-thaw-versions RET. This will revert things back to what you've got in the lockfile.

If your lockfile is updated, you can simply revert whatever changes were made (you are using version control, right?).

→ Manual Intervention

Sometimes you may end up needing to manually intervene when updating a package. In my experience it's pretty rare, but you should be prepared for the possibility. In my case I had to manually intervene when some repo changed their primary branch name, but if you've made local changes to any packages that'd be another instance where you may need to tell straight.el what to do. ¹

→ Conclusion

When I planned this post, I guess I thought there'd be more to talk about but this is really it. When you're using straight.el at least, the process of updating packages is pretty simple and boring. As I mentioned, I usually only think about updates when I see news about something updating, but it's great that I can have a simple, flexible update process along with the power and control I'm afforded by straight.el and use-package.

In part two of this series, I'll talk about updating my setup by way of adding something new. Until then, happy Emacsing!

→ Footnotes And References

Source link for this page