This is to avoid unwanted side effects when installing a wrapped emacs in the environment:
* All executables in the dependencies become available in the user environment
* All site-lisp binaries in the dependencies become accessible to unwrapped emacs
Also, both bin and site-lisp would generate conflicts so installing a wrapped emacs becomes really cumbersome
Building packages requires package-build.el from Melpa, but installing
packages only requires package.el. Packages from ELPA are already built,
so there is no need to involve package-build.el.
When building a package from a Melpa recipe file, get the Emacs package
name from the recipe. Nix is more restrictive about packages names than
Emacs, so the Nix name for a package is sometimes different.
Fixes#10819. emacsWithPackages will know its own package set. This
requires it to be in a package set, rather than at the top level, so it
lives in emacsPackagesNg.
Emacs packages are commonly distributed as single .el files. This
unpackCmd handles them correctly and sets up sourceRoot. Other sources
are treated in the default manner.
Emacs will call package-initialize itself, if required, or the user will
call it in their initialization file. There is no reason to call it in
the wrapper and doing so only increases start-up time.
This simplifies melpa builder by merging with it my old emacs modes builder,
adds better instructions and support for overrides in emacs-packages.nix,
and renames some emacs-related stuff in all-packages.nix for sanity reasons.
I declare this backwards compatible since direct uses of emacsPackages in
configuration.nix are very unlikely.
