Moving Doom's modules out of core

[hlissner]

Important

This was completed as of https://github.com/doomemacs/core/tree/v2.2.0. If for whatever reason you have issues doom upgradeing to v2.2, you can upgrade manually with:

cd ~/.emacs.d
git pull --rebase
git submodule update -f --init --recursive
doom sync -u

This weekend I'm moving Doom's modules to their own repo with git subtree split and a force push. Then it'll be made a submodule of doomemacs/doomemacs until v3¹. Starting now, pull requests targeting modules will be refused and old issues/PRs will be closed, deleted², or transferred, with notice. Once the move is complete (on Monday), I'll rename doomemacs/doomemacs to doomemacs/core and bump it to v2.2.0.

If you have any open issues or PRs to Doom's modules, it'd be a big help if you either closed them (if no longer relevant), pinged me from them (if they still are), or rebased them onto the new repo (once I've pushed it tonight or tomorrow). If your PR has been labeled "was:moved", that means I had intended to address them a different way (which is likely blocked by work elsewhere); rest assured your PR isn't forgotten, even if I end up closing it.

This is one important step toward the larger v3 release. The two projects' development cycles, versioning strategies, maintenance needs, and goals are too distinct to be housed in one repo. Plus, it allows folks to use Doom without its modules (and later, with 3rd party module libraries).³

How it'll affect users

Most users shouldn't be affected by this change. Github handles the redirect from the old name, doom upgrade has been modified to update submodules, and there aren't any breaking changes that should affect your configs, but it might affect projects (or forks) with local changes to modules/*, e.g. nix-doom-emacs-unstraightened (@marienz) or anyone who's done similar in Guix. Feel free to @ me; I'm happy to help.

Footnotes

1. In v3, there will be a doom! syntax for pulling modules and module libraries from arbitrary remotes, much like you can track packages with package!. ↩

2. To reduce search engine pollution I delete issues that provide little value to posterity (e.g. denvercoder issues, local/config issues, duplicates, non-issues, etc) or will likely never be followed up on (e.g. the author deleted their Github account). ↩

3. I'm expanding doomemacs/core's capabilities as a general elisp project tool (mostly to manage the rest of the ecosystem), with stable, long-supported releases and fewer core dependencies (ideally down to 1 or 2 — that being Straight/Elpaca, plus a small list of core modules).

   And doomemacs/modules (and later doomemacs/modules-contrib) will be Doom's "starter kit", intended to be rolling release (I can't control for breaking changes upstream). ↩

[marienz]

nix-doom-emacs-unstraightened (@marienz)

Thanks for the ping. Opened marienz/nix-doom-emacs-unstraightened#128. Looks straightforward (just need to add the equivalent of the submodule bits recently added to Doom's lisp/cli/upgrade.el to our build and CI, more or less).

Looking forward to v3 :)

[nqminhuit]

maybe typo:

$ git submodules update -f --init --recursive
git: 'submodules' is not a git command. See 'git --help'.

The most similar command is
	submodule

[hlissner]

Whoops. Good catch! Fixed.