-
-
Notifications
You must be signed in to change notification settings - Fork 35
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Overriding exec-path changes from other hooks #19
Comments
I can't find the other issue or PR where I discussed this with a contributor, but essentially, if your In this regard, then, |
That makes sense. I didn't think of how having both values out of sync could break things, when the executable tries to run other executables then. In this particular case it would be fine. I would prefer not to extend the path in I can workaround it though. Thanks! |
Oof, I just ran into this issue. I'm a Nix/NixOS user and I don't like installing binaries globally if I can avoid it. Of course, the Emacs packages I use sometimes require that certain binaries are installed. I have provided them to Emacs by wrapping Emacs using This works, and it's not caused any problems with your package. However, one thing that's always annoyed me about this approach is that when I then open a shell in Emacs, that shell inherits this Emacs-specific Today I decided to try and find out whether there's a way to tell Emacs where to look for executables without inadvertently adding those to the
So instead of adding those paths to
This confuses me somewhat. Seems to me that they serve similar (overlapping even, perhaps) but not exactly the same purposes, otherwise why would Emacs:
I think the correct behaviour here might be to apply the same changes that direnv applies to the For users that do keep This reminds me a little of a similar issue I once had with |
Currently blocked by purcell/envrc#19
@zeorin are you looking for exec-path-from-shell perhaps? |
@purcell No, in my case I'm intentionally trying not to completely sync (let* ((prev-path (parse-colon-path (cdr (assoc "PATH" (cdr (assoc "p" result))))))
(next-path (parse-colon-path (cdr (assoc "PATH" (cdr (assoc "n" result))))))
(path-removed (cl-set-difference prev-path next-path))
(path-added (cl-set-difference next-path prev-path)))
(setq-local exec-path (append path-added (cl-set-difference (default-value 'exec-path) path-removed))) |
Ah, that seems like an
I looked at your code, thanks! Isn't this equivalent to keeping |
I would definitely consider merging a corresponding change. I wonder if we can assume that entries unique to |
That could possibly re-order some things in rare cases.
My implementation is a bit naïve, as there's no guarantee that the additions should go to the front, though I imagine that's what ~100% of the time is the intention. Ideally the changes should be merged like a patch EDIT:
More specifically, if there's a "conflict" for adding some "lines", accept both changes, but put the changes coming from If the user needs even more project-specific changes to |
Thinking about this a little more, I would not assume this. Imagine the following scenario:
This is why I took my approach of figuring out the differences instead. This preserves more of the order than the above approach, though as I mentioned, it's still a little naïve. I know this all seems like splitting hairs, but:
|
Nice. Well I'll see if I can find a little time to implement something similar.
Haha, so true! |
This sounds familiar to some of the other issues reported.
In summary,
envrc
will override the changes that hooks might do to theexec-path
.In my case, I do use also add-node-modules-path, which will add some elements to the
exec-path
. But this seemed not to have any effect if envrc is enabled.Looking at the code, envrc is very careful to merge emacs
PATH
and the value read from the.envrc
file. But it is looking at thePATH
environment variable, not theexec-path
. So the exec-path is effectively reset.https://github.com/purcell/envrc/blob/master/envrc.el#L288-L289
Should the merged environment consider
exec-path
too, or would it break things?The text was updated successfully, but these errors were encountered: