spacemacs does not use PATH from nix-shell

[ublubu]

I have a nix-shell set up for my haskell project. I want to run spacemacs in this nix-shell so it has access to all the project's dependencies and matching tools - i.e. ghc, cabal, ghc-mod, lens, mtl, etc

nix-shell configuration: https://gist.github.com/ublubu/e99f7b3282e7c236ac1b

In nix-shell, my PATH has everything I need. In particular, it has this: /nix/store/mr9s0r4bxb85vqh6i7l0as2nxq7fr492-ghc-7.8.4/bin

If I run a vanilla emacs from the nix-shell (by typing emacs [RET] after moving ~/.emacs.d), its exec-path contains everything I expect (C-h v exec-path [RET]). However, when I run spacemacs (typing emacs [RET]), its exec-path does not. Furthermore, the "original value" listed by <SPC> h d v "exec-path" does not contain the expected paths.

I also tried, just for the sake of exploration, adding a line akin to https://github.com/ianbattersby/dotfiles.emacs/blob/master/spacemacs.symlink#L171 in my .spacemacs file: (add-to-list 'exec-path "/nix/store/mr9s0r4bxb85vqh6i7l0as2nxq7fr492-ghc-7.8.4/bin") But that entry didn't show up in my exec-path either.

This is probably redundant, but I also tried this after seeing exec-path-from-shell: If I run $SHELL -c "echo $PATH > blah.txt" in spacemacs and emacs, the results match their respective exec-path values.

How can I get spacemacs to pick up PATH from the environment where it is invoked - the way plain emacs does?

[ublubu]

FWIW, the "original value" of exec-path in spacemacs is the same outside the nix-shell (started from a normal terminal) as it is inside the nix-shell. It seems like spacemacs is unaware of the nix-shell it is started in - in addition to nuking the "original value" of exec-path (Where/When does this happen?).

[ublubu]

https://github.com/syl20bnr/spacemacs/blob/master/spacemacs/packages.el#L1035

Found it. Once I disable the initialization of exec-path-from-shell (e.g. by deleting x from the condition), the nix-shell path is used as expected. What do we need exec-path-from-shell for? Is it safe to turn off? In this case, at least, it doesn't even do what it's supposed to do.

[jb55]

It's used in osx when launching from the app so that the paths are set up correctly. I ran into the same nix path issue as well and it took me awhile to figure out how to fix it.

Us nix users are probably the minority though, it would be great if someone started some nix with spacemacs documentation.

[ublubu]

@jb55: Hahaha where were you five days ago / did you already file an issue for this? But seriously, I like this idea about docs. What other issues have you run into? It sounds like (?) you've been at this longer than I have. Want to start the docs?

everyone: If exec-path-from-shell is only needed for OSX, why do we use it everywhere else, too?

[travisbhartwell]

+1 on the Nix with Spacemacs documentation.

Fellow Nix user here. Nafai on #nixos on Freenode. Would love to collaborate on docs and figuring out this stuff. Particularly the best strategies for doing Haskell and Python development (which would be the two I'm most likely to do) on Nix OS with Spacemacs.

[travisbhartwell]

Regarding docs, would it be useful to create another issue to track issues that we need to figure out and document?

[CestDiego]

What about this? https://github.com/purcell/exec-path-from-shell

[ajrouvoet]

+1 Very annoying bug

[travisbhartwell]

To get around this, I have added exec-path-from-shell to my dotspacemacs-excluded-packages list:

   dotspacemacs-excluded-packages '(exec-path-from-shell)

Since we now have a nixos layer, would it be reasonable to add exec-path-from-shell to the excluded packages of that layer, since this is likely the right thing for all Nix OS users?

If there is consensus that this is the right thing to do, I can make a pull request making that change.

[StreakyCobra]

@ublubu (and @travisbhartwell maybe) We are doing a cleanup of issues. Is this one still valid? If not, it would be nice if we can close it. If yes, it seems an easy PR can solve it, could anyone create it? Thanks :smile:

[travisbhartwell]

I don't currently have the workaround in place as mentioned above, so this is with a somewhat default configuration. I just did a quick test by launching Spacemacs from within a nix-shell and indeed exec-path is incorrect, it is the original PATH value (I'm assuming of a bash login shell) and not what is set in the nix-shell environment it is launched from.

Unfortunately, just excluding exec-path-from-shell isn't a good solution because other layers that could be used on Nix OS rely on it -- the rust layer, for example. That's why I reverted the work around I mentioned previously.

I'll need to look into this more closely to see what's the appropriate way to work with this.

[StreakyCobra]

@travisbhartwell :+1: Thanks for the feedback, It is indeed a bug :smile:

[joefiorini]

A few months later, but fwiw I had the same issue in Fish shell on OSX. Adding exec-path-from-shell to dotspacemacs-excluded-packages fixed it for me.

[jb55]

So the problem with adding exec-path-from-shell to excluded packages is that some layers seem to require it, such as rust and go. This is kind of awkward, which means I can't use these layers.

[CestDiego]

This is something that should be addressed by @syl20bnr if it really has to do with package dependencies in layers

On Thu, Feb 18, 2016, 10:54 PM William Casarin notifications@github.com wrote:

So the problem with adding exec-path-from-shell to excluded packages is that some layers seem to require it, such as rust and go. This is kind of awkward, which means I can't use these layers.

— Reply to this email directly or view it on GitHub https://github.com/syl20bnr/spacemacs/issues/2294#issuecomment-186040619 .

Diego Berrocal http://cestdiego.github.io

[StreakyCobra]

@jb55 You can try what I've explained here, i.e. to modify exec-path-from-shell to only set variables like GOPATH, RUST…, etc… so that PATH is not modified.

[cdepillabout]

I ran into this as well. I'm not using NixOS. I'm using nix on Arch Linux.

I imagine that exec-path-from-shell is nice to have for users on OSX, but as a Linux user it feels very unintuitive. As a novice emacs user, it took quite a long time to figure out why my PATH was being overwritten.

I feel that something unintuitive like exec-path-from-shell should be opt-in rather than opt-out (at least for Linux users).

[teburd]

I was just bit by this bug, very very annoying to even discover.

[Rotaerk]

Actually, I just encountered this as well, and my work around is not to disable exec-path-from-shell, but rather to change the value of the exec-path-from-shell-variables variable. It defaults to ("PATH" "MANPATH") but I changed it to nil and now my path is correct. I'm not sure if this impacts Rust or Go any differently than the other workaround, though; haven't tested.

[langston-barrett]

None of the above-mentioned workarounds solve the problem for me. Bizarrely, this StackOverflow answer did:

nix-shell --pure shell.nix
emacs --daemon
emacsclient -c -a emacs

What changes about the treatment of environment variables when Spacemacs is started in daemon mode? Can we leverage that as a solution?

[langston-barrett]

A more sensible workaround is to use emacs-direnv, and put the following in <project-root>/.envrc:

use_nix <default or shell>.nix

[JonathanReeve]

@siddharthist, could you explain how to use emacs-direnv? Here's what I've tried:

1. Putting use_nix shell.nix in the .envrc in my project's root (which has a shell.nix).
2. Installing direnv.
3. Running direnv allow in the project root.
4. Installing emacs-direnv, then enabling direnv-mode.
5. Running M-x direnv-update-environment

Am I missing something? I still can't get it to work. I'm running emacs in daemon mode as a system service, by the way, in NixOS.

[seanparsons]

I'm using direnv without the Emacs plugin and I can see GHC in exec-path, but when something like Dante or company-ghci try to run cabal then it fails because cabal can't see GHC. Stealth edit: These issues seem to be occurring in develop, not master.

[langston-barrett]

@seanparsons When using Dante, you can put this in a .dir-locals file:

((haskell-mode
  . ((dante-repl-command-line . ("nix-shell" "default.nix" "--pure" "--run" "cabal new-configure && cabal repl lib:your-lib-here --builddir=dist/dante")))))

[seanparsons]

@siddharthist You hero!

[github-actions[bot]]

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!

[langston-barrett]

Still valid.

[zeta-00]

@langston-barrett , adding: use_nix shell.nix to .envrc works, but for some reason it opens another emacs application with everything working correctly, that defeats the purpose of using lorri+direnv+emacs-direnv with the lorri shell command.

Is there a way to get this use_nix shell.nix command in .envrc working with this setup without having to spawn another emacs application? with all my other shell.nix projects, after i initialize everything in a shell in emacs(M-x shell), then, all i need to do is run lorri shell and everything works correctly, but for some reason i'm only having issues when running ihaskell with emacs-ipython-notebook in emacs(M-x ein:run), for some reason it is not detecting jupyter? that's why i'm here trying to find a correct fix for this issue.

[zeta-00]

@langston-barrett , i think this exec-path-from-shell is only for osx users, so i don't think that i need to set it up(it looks to complicated as well):

https://github.com/purcell/exec-path-from-shell

[magthe]

Just thought I'd report that I've managed to get emacs-direnv to work with nix-shell+direnv on my Arch box. Keeping an eye on the *direnv* buffer and solving issue by issue popping up there was the key to my success.

My layer for direnv looks like this:

packages.el:

(defconst direnv-packages
      '(direnv))

(defun direnv/init-direnv ()
  (use-package direnv
    :init
    (progn
      (direnv-mode))))

[blablablerg]

weird bug, I can get it to work running emacs as daemon or using emacs -nw.

[blablablerg]

hmm.. I managed to make it work by commenting (spacemacs/load-spacemacs-env) out in the spacemacs dotfile, leaving defun dotspacemacs/user-env () empty.

Everything seems to work fine so far.. does this have any other unforeseen impact?

btw I am on NixOS 21.05, using the default emacs package.

[github-actions[bot]]

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!