homebrew-emacs-plus
homebrew-emacs-plus copied to clipboard
d12frosted
Issue with PATH injection
I run brew install emacs-plus in a zsh shell with a PATH value set to /usr/local/lib/ruby/gems/3.0.0/bin:/usr/local/lib/ruby/gems/3.1.0/bin:/usr/local/opt/ruby/bin:/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:/Library/Apple/usr/bin:/Users/matthias/.volta/bin:/Users/matthias/.cargo/bin:/Users/matthias/bin:/usr/local/opt/fzf/bin.
The value that ends up in Info.plist is /usr/bin:/bin:/usr/sbin:/sbin.
Running brew reinstall emacs-plus@28 sets the correct path value. However brew uninstall emacs-plus@28; brew install emacs-plus@28 again only sets /usr/bin:/bin:/usr/sbin:/sbin.
Edit: I did some cursory debugging. I think this is a result of Homebrew configuring the environment differently depending on how you install.
I actually install through a Brewfile, most commonly (brew bundle install …), and doing that gives a third PATH value. (/usr/local/Homebrew/Library/Taps/gromgit/homebrew-fuse/cmd:/usr/local/Homebrew/Library/Taps/homebrew/homebrew-core/cmd:/usr/local/Homebrew/Library/Taps/homebrew/homebrew-cask/cmd:/usr/local/Homebrew/Library/Taps/homebrew/homebrew-bundle/cmd:/usr/bin:/bin:/usr/sbin:/sbin).
I wonder if, instead of trying to inherit a path value from the shell that installs Emacs, if it's worth taking an approach closer to exec-path-from-shell and calling $SHELL and then reading the PATH value of a login shell.
@MatthiasPortzel your idea sounds good. Theoretically, implementing it means two things: (a) we retain user intended PATH value and (b) we can return to regular brew environment.
If anyone is willing to contribute, that would be awesome :) just saying..
With a package like exec-path-from-shell existing to fill this purpose, is it worth keeping this PATH setting in the formula? I spent hours the past couple days trying to figure out where a mysterious PATH entry in my Emacs was coming from before I realized it was coming from this formula.
I think it's probably very convenient for some users, but maybe it'd be better as an FAQ that says "install exec-path-from-shell"?
I also fully recognize removing this injection might confuse a bunch of people just as badly as I was confused, but in the other direction. I also want to acknowledge and appreciate the work you've done to make things easy. So, I defer to your judgment in the end!
With a package like exec-path-from-shell existing to fill this purpose, is it worth keeping this PATH setting in the formula?
Yes, it's still needed. In some cases (especially for native-comp feature), exec-path-from-shell is loaded too late. At least, to my understanding.
I spent hours the past couple days trying to figure out where a mysterious PATH entry in my Emacs was coming from before I realized it was coming from this formula.
If you are using exec-path-from-shell this should not happen. Sorry to hear that you've spent so much time figuring what changed the value of PATH. Definitely not something I wanted to achieve with this change.
I think it's probably very convenient for some users, but maybe it'd be better as an FAQ that says "install exec-path-from-shell"?
You can read more about this feature in the README. And more details can be found in this blog post.
I also fully recognize removing this injection might confuse a bunch of people just as badly as I was confused, but in the other direction.
Aye, it's not easy to decide, what is the right default here. My thinking is simple. Advanced users already know about exec-path-from-shell package, and every "problem" caused by injected PATH can be solved with that package (because it's fundamentally the same "problem" as without injected PATH). But there are enough people that (a) new to Emacs and (b) do not understand what environment macOS uses for applications running from Finder/Spotlight/launchd/etc. And since (a) it's something very macOS-specific and (b) it's effect can be easily changed by using common package, I decided to provide this functionality that injects PATH during installation by default.
WDYT?
Yeah, I think that's right. It's probably rare that anyone has the problem that I had, where an old PATH entry from compile time was causing a problem even with exec-path-from-shell.
I think this is the right call. Thanks for taking the time to think about it again, though.
It's probably rare that anyone has the problem that I had, where an old PATH entry from compile time was causing a problem even with exec-path-from-shell.
Oh, if you don't mind, can you please explain the problem in more details? My decision is kind of based on premise that exec-path-from-shell covers all corner cases.
I even remember having to run the pbd commands in the past to get native comp working. How quickly I forgot.
Sorry, I missed your last question. I'm sorry I cannot remember the details anymore. It was rather obscure. Something to do with old shims from nvm installed in a non-standard location or something, that had previously been on my PATH but was no longer.
Again, I think I've come around to agreeing with the current behavior. 🙇🏻
