[Feature]: Recipe for bootstrapping via `package.el`

[michaelmhoffman]

Feature Description

As far as I can tell, Elpaca isn't in the melpa, nongnu, or gnu repositories. Bootstrapping seems fairly involved.

Would you consider making a recipe that would work with package.el and submitting it to one of the above? I know some early-init.el and init.el changes would still be necessary, but maybe the recipe could produce those.

This would make it a lot easier to try out Elpaca. I must admit I haven't tried out straight.el or Elpaca after years because every time I look into it, it always seems so involved.

Thank you for making this neat software!

Confirmation

• [X] The feature I'm proposing does not already exist in Elpaca

[progfolio]

As far as I can tell, Elpaca isn't in the melpa, nongnu, or gnu repositories. Would you consider making a recipe that would work with package.el and submitting it to one of the above?

Here is previous discussion about adding straight.el to MELPA:

https://github.com/melpa/melpa/issues/4939

https://github.com/radian-software/straight.el/issues/134

https://github.com/radian-software/straight.el/issues/648

Long story short, I don't think such a proposal would be in line with the goals of such repositories. It would also be a maintenance burden I'd like to avoid.

Bootstrapping seems fairly involved.

If you are running Emacs version 29 or greater, the --init-directory command-line option can set user-emacs-directory. Then it's a matter of downloading the demo early-init.el and demo init.el files in this repo's docs directory into a directory of your choice. Lastly, emacs can be started using that directory as user-emacs-directory.

emacs --init-directory=/path/to/downloaded/files/

Or, even simpler, clone Elpaca's repository and point --init-directory to the Elpaca's docs directory. e.g.

$ git clone https://www.github.com/progfolio/elpaca.git
$ emacs --init-directory="./elpaca/doc/"

One technique is to migrate your init file piece by piece this way. That way the original is untouched and you can always go back to it, should you need to. Migration is typically low-effort, depending on one's setup, though. Elpaca has use-package integration which makes most use-package forms which were installing packages via package.el "just work" for Elpaca. e.g.

;; Assuming elpaca-use-package-mode enabled...
(use-package example :ensure t) ;... this should install the "example" package via Elpaca now.

For Emacs versions prior to 29 there are tools like https://github.com/plexus/chemacs2.

I know some early-init.el and init.el changes would still be necessary, but maybe the recipe could produce those.

Right, it would be impossible to catch all cases as users are free to customize their init files however they please. Elpaca currently has warnings/errors in place if:

• The git executable is not found on PATH
• Package.el is activated prior to Elpaca
• Another version of a package is loaded prior to requesting it be activated via Elpaca.

Those cover many common issues I saw crop up when people were migrating to straight.el from another package manager.

I must admit I haven't tried out straight.el or Elpaca after years because every time I look into it, it always seems so involved.

I would try the above method of creating a temporary directory to play around in. It shouldn't take too much effort. I'm happy to further provide support if you run into any issues in getting that set up, too.

Thank you for making this neat software!

Thank you for the kind words and taking the time to write up the suggestion.