Is the comparison section fair?

[raxod502]

Hello, maintainers of prominent package managers for Emacs!

As you might have noticed, I've written a package manager too. Since there are so many options, I took a weekend to learn as much as possible about the existing solutions, and wrote up a very detailed comparison section.

I wanted to take this opportunity to solicit feedback, since I most certainly don't want to write unfair or inaccurate things about other people's work. If you see anything that is wrong, misleading, or omitted, please tell me and I will correct it.

Package managers and maintainers:

• package.el — Comparison section — Maintainers: ???
• Quelpa — Comparison section — Maintainers: @steckerhalter, @wasamasa
• Cask — Comparison section — Maintainers: @rejeep, @lunaryorn
• el-get — Comparison section — Maintainers: @dimitri, ???
• Borg — Comparison section — Maintainers: @tarsius
• DELPS — Comparison section coming soon, see Comparison with DELPS #90

Quoting from flycheck/flycheck#649:

If you'd not like to join this discussion, please feel free to ignore my having mentioned you and please excuse the unsolicited spam. But I'd really appreciate your feedback and your ideas on this subject. Please feel free to invite other people to this discussion if you consider their opinion important or interesting.

[wasamasa]

The author of package.el would be @tromey.

As for the discussion, sorry, the README is anything but straight-forward. I'd rather put the comparison section into a separate document, that wall of text is just going to scare off anyone who is considering to give your package manager a try.

[raxod502]

@wasamasa Thanks for the feedback. I was already considering splitting the README into multiple documents, since the table of contents can only take you so far. (For the purposes of this discussion, though, my original post links directly to the comparison sections for each package manager.)

[dimitri]

It would be fair to add @npostavs as El-Get maintainer. Also the main aspect differenciating el-get from the other choices nowadays would be:

• el-get works with recipes that are easy to share in between users without any centralized setup, just send them over (e.g. by email) and get started,

• el-get package management includes advanced option for per-package init files and setup.

Also el-get predates most other systems and inspired some of them (like https://melpa.org/#/) and I think it did put some good pressure on package.el and ELPA to become what it is now.

[npostavs]

straight.el provides a suite of powerful interactive tools for performing bulk operations on your package's Git repositories. el-get only allows you to install, uninstall, and update packages noninteractively.

el-get allows you to do those things interactively as well (I think you just meant that el-get doesn't perform operations on the package's git repository for you, outside of the ones performed by install, uninstall, and update).

[raxod502]

@dimitri:

• straight.el also uses recipes that are easy to share (they are just in a slightly different format, but still basically a property list), so I do not think this is a difference between the two of them (although it is certainly a difference between el-get and other package managers).

• I've updated the note about per-package init files for el-get:

  • el-get provides a number of features for running per-package initialization and setup code, including pulling that code from arbitrary sources. straight.el does not support this and expects you to use a dedicated tool like use-package (with which integration is built in) for that purpose.

@npostavs:

When I said "interactive", I didn't just mean (interactive) in the Elisp sense, but this:

_{(ignore the "merge nil to branch" message, that is because #59 has not been fixed yet)}

Does el-get also provide such features? If not, I will reword to make it clear what I mean by interactive, so as not to imply that you can't use M-x to manage your packages in el-get.

[npostavs]

el-get provides a package list interface, somewhat similar to package.el's list-packages which lets you install, update, and remove packages (in addition to M-x el-get-install, etc). It does not provide any interface for managing the corresponding git/hg/svn/etc repositories (except in the indirect sense that the package commands update the repositories).

[raxod502]

Thanks. I didn't know that el-get had a list-packages-like interface for package management. I've added a note accordingly:

• el-get has a user interface for package management that also displays package metadata, similarly to package.el. straight.el has no user interface for package management; any UI is provided by the user's completing-read framework.

Also, I reworded some of the sections discussing straight.el to refer to "interactive workflows" rather than "interactive commands". Hopefully that will make the idea clearer.

[tarsius]

It is fair and I found it fun to read. Also I think that it helps reading someone else's description of you own implementation. Some statements are not 100% accurate or complete.

On ther other hand,

On the other hand,

• straight.el supports GNU ELPA, MELPA, EmacsMirror, and custom recipe sources. Borg only supports EmacsMirror.

... but because the Emacsmirror contains all packages that are available from GNU ELPA and MELPA (and then a few hundred more), that doesn't make much of a difference. (Except that there sometimes is a delay before a new package gets added to the Emacsmirror. Not more than a few days usually.)

• straight.el allows you to specify a custom recipe to install a package from any Git repository. It appears that achieving the same with Borg requires updating the EmacsMirror.

The Emacsmirror isn't needed at all. To install a package you have to specify the name of the package and the url of an appropriate Git repository. If the package is available from the Emacsmirror, then you only have to specify the name and borg will automatically clone from the upstream repository if upstream uses Git, or from the Emacsmirror otherwise. (In the next release it will be possible to specify an alternative url even for packages that are mirrored. Currently you have to "fix" the url/remote after cloning).

If a package needs special build steps, then those can be defined in ~/.emacs.d/.gitmodules. Currently this is a bit cumbersome as far as sharing such "recipes" and avoiding an initial failed build attempt goes, but that too will be improved in the next release.

[raxod502]

Thanks. I've amended the note about recipe sources:

• straight.el supports GNU ELPA, MELPA, EmacsMirror, and custom
  recipe sources. Borg only supports EmacsMirror and custom recipe
  sources. However, as the EmacsMirror is a complete superset of both
  GNU ELPA and MELPA, this does not mean you have access to more
  packages: it just means you benefit from the recipe maintenance
  efforts of the MELPA team and the EmacsMirror team, rather than only
  the latter.

I've also removed the note about custom recipe specifications, since it sounds like Borg and straight.el are equally capable in that regard.

Finally, I added some notes about the profile system to all subsections of the comparisons section, since I think it is unique to straight.el.

[vyp]

This package looks nice! I might try it some time. ✨ Can you also add a comparison to nix?