syl20bnr / spacemacs

A community-driven Emacs distribution - The best editor is neither Emacs nor Vim, it's Emacs *and* Vim!
http://spacemacs.org
GNU General Public License v3.0
23.69k stars 4.9k forks source link

New env var caching breaks git gpg signing #10851

Closed aaronjensen closed 4 years ago

aaronjensen commented 6 years ago

Description :octocat:

c12b72090 Cache PATH and env vars. fetched with exec-path-from-shell

That commit breaks gpg signing with magit by preventing git from finding gpg in the path. I don't know how or why, but it does. It probably breaks other things, but this is the first I noticed.

Reproduction guide :beetle:

Observed behaviour: :eyes: :broken_heart:

hint: Waiting for your editor to close the file...
Waiting for Emacs...
fatal: cannot run gpg: No such file or directory
error: gpg failed to sign the data
fatal: failed to write commit object

Expected behaviour: :heart: :smile:

Successful commit

System Info :computer:

ljupchokotev commented 6 years ago

There is another issue with this commit as well. If you start emacs in daemon mode, the .env-vars file will never get created because of the (when (display-graphic-p) line. The .env-vars file should be created when starting in daemon mode too.

Also, if I run spacemacs/import-path, it won't actually import GOPATH (which is needed for the go layer), it will only import the PATH environment variable.

syl20bnr commented 6 years ago

I think we need two cache files, one for the terminal and one for the GUI as the environments can be different.

@ljupchokotev GOPATH will be cached again at the next startup, see documentation: https://github.com/syl20bnr/spacemacs/blob/develop/doc/DOCUMENTATION.org#environment-variables-and-path-from-the-shell ;-)

syl20bnr commented 6 years ago

as the environments can be different.

Explanation on this. A user can use two different shells, say bash as default shell and fish as "work related" shell. When emacs is invoked from fish then it inherits its environment, when it is invoked outside a terminal it will inherit the environment from the default shell, in this case bash leading to different sets of variables and values.

ljupchokotev commented 6 years ago

@syl20bnr I did a simple test to see what happens:

  1. Remove the .env-vars file if it already exists, so we start with a clean state
  2. Run emacs --daemon This gives me the following errors: Error (use-package): go-mode/:init: Opening input file: No such file or directory, /home/bubo/.emacs.d/.cache/.env-vars Error (use-package): rust-mode/:init: Opening input file: No such file or directory, /home/bubo/.emacs.d/.cache/.env-vars

The .env-vars file is not created in this step.

  1. Open a go file with emacsclient -c This doesn't create the .env-vars file as well. Does this mean GOPATH will not be available to Spacemacs?
  2. Run SPC SPC spacemacs/import-path .env-vars is created now only consisting of exec-path. No go related environment variables are set.
  3. Close the emacsclient and run it again by opening a go file Both GOROOT and GO15VENDOREXPERIMENT are added to .env-vars with "NOTFOUND-PLEASE-DEFINE-IN-YOUR-SHELL" which is fine since I don't have those defined. I do have GOPATH defined and that one isn't added to the .env-vars file.

I am not sure if this is expected behaviour.

Also, if I don't use daemon mode and run emacs main.go, this creates the .env-vars file immediately but is still missing GOPATH while it has both GOROOT and GO15VENDOREXPERIMENT which I don't have defined.

syl20bnr commented 6 years ago

Seems quite buggy in the current state, thanks for the explanation. Actually when starting from the terminal exec-path-from-shell should not be needed as Emacs should pickup the environment just fine if it has been launched with the right user. I may be mistaken though, I'll have to triple check this.

thatnerdjosh commented 6 years ago

@syl20bnr Is there a way to tell emacs that GOROOT is optional? This breaks stdlib autocomplete with it setting to GOROOT-NOTFOUND-PLEASE-DEFINE-IN-YOUR-SHELL

aaronjensen commented 6 years ago

Hey there, sorry, I think this issue has been co-opted as the original issue has nothing to do with running from the terminal.

The issue is that this exec path stuff breaks pretty much everything on macOS (at least on my config).

It's not just gpg signing, but the typescript-tslint checker (it can't find node anymore) and probably other things. I don't know yet what causes it, but reverting the commit fixes everything. Could we just revert the commit for now until we understand the issue?

syl20bnr commented 6 years ago

Work-around found in this message: https://github.com/syl20bnr/spacemacs/issues/10867#issuecomment-396949381

syl20bnr commented 6 years ago

Should be fixed in develop, relevant commits:

The fetch is asynchronous, it should not be a problem but if we encounter some issue I'll add a hook to be able to do some post processing once the env. vars are fetched.

syl20bnr commented 6 years ago

Thank you @fiveNinePlusR for the original PR 💜

aaronjensen commented 6 years ago

Works for me, thanks!

myme5261314 commented 6 years ago

Seems still no working. The issue I encountered in #10883 solves. But exec-path and PATH in Emacs.app running GUI instance is different from my zsh environment variables. This makes the error message during Emcas.app startup.

Warning (ox-pandoc): Pandoc command is not installed.
Error enabling Flyspell mode:
(Searching for program No such file or directory ispell)

But pandoc and ispell is installed.

-> % which pandoc
/usr/local/bin/pandoc
-> % which ispell
/usr/local/bin/ispell
-> % which zsh
/bin/zsh

The PATH and exec-path in Emcas.app is /usr/bin:/bin:/usr/sbin:/sbin:/Applications/Emacs.app/Contents/MacOS/bin-x86_64-10_10:/Applications/Emacs.app/Contents/MacOS/libexec-x86_64-10_10 Value of dotspacemacs-import-env-vars-from-shell is t. Value of dotspacemacs-import-env-vars-shell-file-name is nil or "/bin/zsh"(both doesn't work).

rpls commented 6 years ago

Another issue i've come across: Environment variables with values containing "=" don't get passed on properly. Important, for example, for example for variables like

DBUS_SESSION_BUS_ADDRESS=unix:abstract=/tmp/dbus-SiK8VZlOYE,guid=c090e6678bbf37caff8a8eb35b278c0d

which will be cached as

DBUS_SESSION_BUS_ADDRESS=unix:abstract

In my case, neither gpg nor msmtp are working, because they can't contact the gnome-keychain for passwords.

Miciah commented 6 years ago

@rpls, that issue has been reported as #10910 and should be fixed by #10909.

JuanCaicedo commented 6 years ago

@myme5261314 I think I'm seeing the same problem as you, but with node. I get often get message saying env: node: No such file or directory. I have node installed using nvm and if I run which nvm inside spacemacs, I see a message nvm not found. Both of these are defined in any terminal session I run, and I'm using emacs as a standalone GUI instead of through the terminal.

My guess is that zsh plugins aren't being initialized. Though if I run echo $0 in spacemacs, I get /usr/local/bin/zsh. Let me know if I can provide more info!

myme5261314 commented 6 years ago

Thanks to @syl20bnr , the commit 6220ace290b247265de8fac66bd9e84bef388326 works. But remaining an issue: On osx, shell initialization will load /etc/paths whose content contains /usr/local/bin, so my zshrc doesn't explicitly add /usr/local/bin to $PATH. But osx GUI application won't load /etc/paths, so /usr/loca/bin will be missing that will make brew installed things missing.

At worst, I can manually append /usr/local/bin to $PATH in zshrc, and it does fix the command not found along with Emacs osx GUI application. But the /usr/local/bin will be duplicated in terminal shell instance.

Compro-Prasad commented 6 years ago

@myme5261314 If you are doing this for Emacs you can use setenv instead of putting it in zshrc.

github-actions[bot] commented 4 years ago

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!