I was hoping to avoid this but it does not seem practical: I'm pretty
sure I need the user module in the store to override its packages.el,
and Doom does not separate the user module and doom-user-dir.
This seems like a relatively sane way of loading our profile from the
Nix store. The alternatives I see are patching Doom (which I'm trying to
avoid) or setting DOOMLOCALDIR. If we set DOOMLOCALDIR, Doom sets enough
variables based on it it would be a pain to clean them up after we gain
control.
Using the profile loader lets us set doom-profile-data-dir early, which
currently only contains the profile and env file.
I haven't fully confirmed this is sufficient to avoid rebuilds, but I
did confirm for a few packages the version no longer appears in that
package's derivation (which should be sufficient).
We were already setting `commit` to `p.pin` unconditionally, so the
requirement is not new. Add an assert because this can be triggered from
a user packages.el.
Drop url overrides no longer needed because Doom now points at
emacsmirror.
The URL overrides weren't breaking things, because emacsmirror mirrors
these repositories unmodified (the commit Doom pins is present in both).
Exposes what I think is a pre-existing problem with too many directories
getting added to load-path, because we now install a directory
containing a file named "default" that was previously omitted.
trivialBuild results in files installed directly into site-lisp/,
without package metadata. This breaks ELPA packages whose dependencies
we've replaced: package.el refuses to activate the ELPA package because
as far as it knows its dependency is not installed.
melpaBuild seems the easiest way of generating an activatable package
that works with packages we leave untouched.
