elpaca package manager, a better package manager

I've rarely run into issues with straight, but I'll still likely check this out.

The instructions tell you to disable package.el. Is this necessary? I would be interested in something to install some packages for development, but stick to the good old released versions from ELPA for the packages I "just use".

Looks really neat.

This looks great. I think that it is always nice to see some rethinking of existing packages (straight.el). There is also some work happening in the main emacs distribution to use packages from source repositories. https://amodernist.com/texts/package-vc.html Even if that goes in, packages like this one will still be useful and may even benefit from the extra metadata in elpa.

I definitely don't know anything about it other than from skimming the GitHub README, so grain of salt and all that. But, I doubt it's strictly necessary. I think the idea is to disable it so that you don't "accidentally" use (part of) it instead of elpaca and then wonder why elpaca isn't properly managing something about your packages.

package.el is designed so that is activates all the packages you have installed on start up. The problem with using a package manager like straight.el or Elpaca at the same time as package.el is they may conflict with eachother when activating packages. I'm sure, with enough effort, they could be made to work together, but it's not on the roadmap for straight or Elpaca. > I would be interested in something to install some packages for development, but stick to the good old released versions from ELPA for the packages I "just use". For straight.el: https://github.com/radian-software/straight.el/tree/develop#how-do-i-pin-package-versions-or-use-only-tagged-releases For Elpaca, a similar lockfile system is in the works. I've also added `:ref`, `:branch`, and `:tag` recipe keywords. There's still work to be done to allow pinning packages, but it should be easier to deal with with these keywords in place from the beginning.

Upvote for the great name.

it's common practice with 3rd party package managers to request the user disable package.el for conflict and performance reasons.

What package.el problem does this package fix? Over the years I’ve seen many package.el replacements or even use-package replacements, but both of which are still going strong. I have few problems with use-package and I can patch over the bugs somewhat in package.el. What other problems are there that I’m missing?

I took a (very) quick scroll through the README, but I didn't quite get it. What are the limitations/issues with straight that this aims to solve? And does it otherwise innovate package management somehow, or is it mostly just "straight in retrospect"?

So, just to verify as a long-time but non-programmer emacs user: * straight.el replaces package.el to use git instead of tarballs and more details to specify specific package versions * elpaca.el is a cleaner, smaller version of straight.el * If I don't need these features and have been happy with M-x list-packages, I should just ignore all of this and keep moving...

Oh, neat! It has a UI? And it's by the author of straight? I'm using straight.el now (vimmer exploring emacs again), and I found it to be excellent, but I do very occasionally miss the simplicity of using a UI to find and install packages.