After more than a year with straight as my package manager, recently I have decided to sit down and look closely at how I handle my Emacs packages.
For all the interesting design choices and splendid documentation straight
offers, I have never used neither its version freezing capabilities nor the
chances to edit the source code of a package to try possible fixes before
sending patches upstream. Two reasons, mainly:
- I update my packages on a daily basis, accepting the risk of breakages in order to signal them to the maintainers and offer some help;
- when I want to send a patch, I have the source code of the package I am working on outside of my Emacs configuration to avoid leaving something messy around.
These are not issues with straight, of course. It all depends on what one needs
from their package manager.
One of the major benefits that straight brought to my setup is a boost in
startup speed. However, why don’t give package-quickstart a try? Setting
package-quickstart to t instructs package.el to pre-compute an autoload
file so that the activation of packages can be done much faster, resulting in a
faster
startup.
And indeed it does, resulting in more or less the same 0.4 seconds that I was
getting with straight.
One thing to be aware of is that, as the documention of package-quickstart
suggests, “the use of ‘package-quickstart-refresh’ every time the activation
need to be changed, such as when ‘package-load-list’ is modified” is required.
Hence, I added an :after-while advice to package-menu-execute (bound to
x
in Package Menu) to make sure package-quickstart-refresh is run
after every upgrade.
Again, mine is not an argument against straight. It’s still a great package
manager and a fantastic alternative to the built-in package.el. However, these
days my Emacs interactions do not need the fine-grained control straight
provides.