spacemacs

spacemacs copied to clipboard

I've been thinking of making the switch to NixOS for a while. With how NixOS tries to subsume all language/software-specific package management, what are the best practices for setting up Spacemacs on a NixOS box? Is it the same "clone into .emacs.d" setup as always, or are you supposed to take advantage of the substantial set of Emacs packages that NixOS can manage on its own?

I've been using NixOS for the past week with spacemacs and all I did was clone into .emacs.d as usual. Although, I noticed that the auto-generated variables that are normally at the bottom of your .spacemacs file don't seem to show up, it's been working fine. All the elixir/alchemist stuff works really well but it always does.

The dream is to build a spacemacs2nix tool to encode emacs dependencies from spacemacs layers into nix expressions. AFAIK there is no way to use emacs packages from your nix store at this time.

see:

• nixos/nixpkgs#9068
• https://gist.github.com/Profpatsch/ddff34d495f57b505a6b

so I have a pretty ghetto hack that seems to work OK:

Prevent deletion of orphaned packages

By setting dotspacemacs-install-packages to 'used-but-keep-unused in dotspacemacs/init in your .spacemacs:

(defun dotspacemacs/init ()
  (setq-default
   dotspacemacs-install-packages 'used-but-keep-unused
   ))

This is a workaround. It's needed because spacemacs can sometimes try to delete stuff from system packages which will crash your startup.

Get a list of all of your installed packages

Use this command:

ls $HOME/.emacs.d/elpa/26.2/develop | sed 's/-[[:digit:]].*//g;s/\+$/-plus/g' | sort -u

You might need to update 26.2 to your version

Paste list into your ~/.nixpkgs/config.nix` overrides:

  packageOverrides = super: rec {
    emacs = super.emacsWithPackages (ep: with ep; [
      ace-jump-helm-line
      ace-link
      ace-window
      ac-ispell
      adaptive-wrap
      aggressive-indent
      alert
      # ... etc
    ]);
}

You might need to comment out any broken packages.

Delete spacemacs' package cache

$ rm -rf ~/.emacs.d/elpa

Try it out

$ nix-shell -Q -p emacs

... this might fail, go back and comment out packages until it works.

$ emacs

done! spacemacs will still install the remaining stuff that isn't in your system packages.

Annoyances

You have to keep your package list updated by repeating this process. but now you have the benefit of a stable set of packages cached in your nix store!

/cc @Profpatsch @CestDiego

To be honest, I’ve just used spacemac’s own declarative package management and updated every month or so. That has worked quite well for me so far.

I would love to be able to have custom Spacemacs distributions available via nix-shell as a way to gently introduce folks at work to reliable, complete, IDE-like command-line editor experiences in development environments. Spacemacs feels great for development in so many languages, and the discoverability is really impressive. The ability to bind unbreakable, pre-configured Spacemacs distros to specific projects would really take what seems to be the central aim of the project (making Emacs more accessible and easier to jump in with but no less powerful) to a whole new level, imo.

But I just started using Spacemacs last week, and I've never used Emacs before then either, so I feel like trying to get this right is a bit out of reach for me.

For my own personal use, the plain old git clone into ~/.emacs.d option has been quite alright, but I do think packaging it with Nix would add some potential for extra niceness (like pinning to a patched or unreleased version of Spacemacs just to get specific features, perhaps particular to a programming language, which haven't been released yet but one knows are stable without risking breakage of other use cases, since they can have their own respective Spacemacsen, too).

but I do think packaging it with Nix would add some potential for extra niceness (like pinning to a patched or unreleased version of Spacemacs just to get specific features, perhaps particular to a programming language, which haven't been released yet but one knows are stable without risking breakage of other use cases, since they can have their own respective Spacemacsen, too).

Isn’t that just checking out a different ref in the spacemacs git repo? There’s not much magic involved.

Yeah, but every user only has one ~/.emacs.d directory. The difficulty I anticipate isn't in making that feature happen, but the more general difficulty of packaging Spacemacs in a natural way (which is why it hasn't happened yet despite some interest). And that's what would get us different ones side-by-side and all the other little things one can just do with Nix packages.

The things I don't know how to do are things like, as was mentioned as a possibility in the thread, 'patch out auto-updating features' or whatever else might be necessary to get this to work seamlessly. I'm sure it can be figured out, but I'll have to spend more time with Emacs in general and Spacemacs in particular before I'll know what to do.

On Tue, Jun 20, 2017, 3:54 AM Profpatsch [email protected] wrote:

but I do think packaging it with Nix would add some potential for extra niceness (like pinning to a patched or unreleased version of Spacemacs just to get specific features, perhaps particular to a programming language, which haven't been released yet but one knows are stable without risking breakage of other use cases, since they can have their own respective Spacemacsen, too).

Isn’t that just checking out a different ref in the spacemacs git repo? There’s not much magic involved.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/syl20bnr/spacemacs/issues/7813#issuecomment-309717689, or mute the thread https://github.com/notifications/unsubscribe-auth/ADCJbjTCy42j7uvxfJblDiednMYG76hHks5sF6TegaJpZM4K6TNp .

@Profpatsch not really, if you delete the elpa dir you get "whatever package version is latest" so there's no consistent reproducible state that spacemacs is in. I've have stuff be completely broken after updating my packages on the same spacemacs commit.

Assuming the last comment is still last year, there is not any alternative isn't it? @jb55

I've got some work here on a spacemacs2nix.el:

https://github.com/puffnfresh/nix-files/tree/master/spacemacs

It kinda works for me, please give it a go and let me know how it goes for you.

A bit relevant https://github.com/syl20bnr/spacemacs/issues/12029

If anyone is interested: I am currently maintaining a fork which solves some NixOS related problems. A derivation which uses this can be found here: https://github.com/timor/timor-overlay/tree/master/pkgs/spacemacs

It uses a slightly patched emacs to run it completely separately from stock emacs from the store, and keeps all user config in the ~/.spacemacs.d directory.

@puffnfresh, I tried your scripts, but unless I'm missing something obvious, the second script is looking for spacemacs-bootstrap.nix, which doesn't seem to exist?

@puffnfresh , @JonathanReeve - do you mean that it doesn't work without that missing file? I'm trying to understand NixOS enough to at least have the default setup working, but it proves very difficult.

I couldn't get it to work. I suspect @puffnfresh didn't check in spacemacs-bootstrap.nix to Git? Anyway there appears to be something missing. Unless I'm doing something wrong.

I got development nicely working by using upcoming spacelpa dotspacemacs-use-spacelpa t All my packages properly install with base emacs 26.1 from 19.09

I was able to re-create the missing spacemacs-bootstrap.nix from @puffnfresh repository:

with import <nixpkgs> {};
emacsWithPackages (ps: with ps; [
  async
  bind-map
  bind-key
  diminish
  evil
  hydra
  use-package
  which-key
  dotenv-mode
  pcre2el
])

However I can still not start the generated spacemacs:

Feb 10 14:44:05 turingmachine zsh[13409]: Warning (initialization): An error occurred while loading ‘/home/joerg/.emacs.d/init.el’:
Feb 10 14:44:05 turingmachine zsh[13409]: error: Recursive ‘require’ for feature ‘pcomplete’
Feb 10 14:44:05 turingmachine zsh[13409]: To ensure normal operation, you should investigate and remove the
Feb 10 14:44:05 turingmachine zsh[13409]: cause of the error in your initialization file.  Start Emacs with
Feb 10 14:44:05 turingmachine zsh[13409]: the ‘--debug-init’ option to view a complete error backtrace.
Feb 10 14:44:05 turingmachine zsh[13409]: Spacemacs is ready.
Feb 10 14:44:05 turingmachine systemd[3378]: Started emacs-daemon.service.

It seems fail to load pcomplete.

So, currently there are 3 approaches?

• spacelpa
• @puffnfresh spacemacs2nix
• @timor overlay

What are the practical differences?

I have not found a working one so far.

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!

This is still a concern.

There seems to be some (unmerged?) relevant work in GUIX: https://issues.guix.gnu.org/38643

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!