spacemacs
spacemacs copied to clipboard
Nonstandard repo location (environment flexibility)
I'm trying to separate my "user specific" and "system provided" files to make my setup a bit nicer for me on NixOS, and for this I would like to separate the spacemacs repository from other files that end up in '.emacs.d'.
I'm new to emacs, how hard would this be to support? Does it work already or will there be lots of insidious breakage? Can I just chain loading through another '.emacs.d/init.el', or how could this work?
An example of how I imagine this could work is having an '.emacs.d/init.el' check an environment variable for the repo path.
I would like to progress towards a separation between my set of immutable (generated/handled by NixOS) configuration files, and other stateful files.
Spacemacs' init.el calls core-load-paths.el which ends up using https://github.com/syl20bnr/spacemacs/blob/c7a103a772d808101d7635ec10f292ab9202d9ee/core/core-load-paths.el#L19-L20 to define some other paths. This relies on emacs-user-directory which is precisely the .emacs.d directory.
Maybe some flexibility could be added here? (and the probably inevitable upstream bug/feature requests to not hardcode paths as much...) Or does anyone know a feasible workaround?
~~Luckily~~ Due to someone's foresight the only other things in the spacemacs repo that seems to directly refer to user-emacs-dir are
https://github.com/syl20bnr/spacemacs/blob/c7a103a772d808101d7635ec10f292ab9202d9ee/core/libs/quelpa.el#L81 https://github.com/syl20bnr/spacemacs/blob/c7a103a772d808101d7635ec10f292ab9202d9ee/core/core-load-paths.el#L44-L45 and grep -irE "user-[a-z0-9]+-directory" doesn't seem to return anything else relevant, but I'm not really familiar with emacs.
A cursory attempt at initializing spacemacs with the following patch appears to behave reasonably, but I don't know how to stress the system. (note: SPACEMACS_REPO requires to be defined with a trailing slash?)
diff --git a/core/core-load-paths.el b/core/core-load-paths.el
index 718b27c..0feeb1a 100644
--- a/core/core-load-paths.el
+++ b/core/core-load-paths.el
@@ -17,7 +17,10 @@
;; paths
(defvar spacemacs-start-directory
- user-emacs-directory
+ (let ((repo (getenv "SPACEMACS_REPO")))
+ (cond
+ (repo repo)
+ (t user-emacs-directory) ) )
"Spacemacs start directory.")
(defconst spacemacs-core-directory
(expand-file-name (concat spacemacs-start-directory "core/"))
Ping @syl20bnr because you have most of the git blames on core-load-paths.el.
Ok since there's a lot of variables that might need to be set, this might be better handled with a configuration file than a big load of environment variables. I don't know how handling this problem should be designed, or how consistency in the spacemacs system can be ensured.
Currently I'm working on getting spacemacs to boot with an immutable repo. This seems to work if additionally configuration-layer--elpa-root-directory in core/core-configuration-layer.el is overridden to point outside the repo directory. e.g.:
ff --git a/core/core-configuration-layer.el b/core/core-configuration-layer.el
index 7e5830c..2d14921 100644
--- a/core/core-configuration-layer.el
+++ b/core/core-configuration-layer.el
@@ -120,7 +120,7 @@ subdirectory of ROOT is used."
"Hook executed at the end of configuration loading.")
(defconst configuration-layer--elpa-root-directory
- (concat spacemacs-start-directory "elpa/")
+ (concat user-emacs-directory "elpa/")
"Spacemacs ELPA root directory.")
(defconst configuration-layer--rollback-root-directory
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Please let us know if this issue is still valid!
Don't you dare.
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Please let us know if this issue is still valid!
Probably still valid.
I agree. It should be possible to be at least as good as spacevim in packaging spacemacs versions.
The package set will always be layer dependent and will to be generated using spacemacs for now, with something like spacemacs2nix for example.
EDIT: Digging through the code and some preliminary testing, adding a --eval '(defvar spacemacs-start-directory "${spacemacs}/")' to the emacs launch args should be enough to run spacemacs e.g. from the nix-store.
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Please let us know if this issue is still valid!