I totally appreciate the effort ... but ... (I also linked to shellenv in #1795 as prior art; my own #1509's def read_env(sink): is a bit more modern even) the main change we need is that we should call this per working_dir so it supports multiple projects simultanously open.

I think shellenvs's method is even corporated into newer Sublime Text bc the recent Sublime version do read the env from the shell and then update os.environ globally.

What #1509 does, it reads from an interactive shell which is a bit more modern and useful probably. (It is slower and that's why Sublime doesn't do it at the startup.)

Within the Linter.get_env we have access to the working dir because it is on self. But the calls to util (which and where for example) don't pass that along at the moment. They all assume a global env and PATH.

Regards

I think shellenvs's method is even corporated into newer Sublime Text

No, it does not. On my machine I always have different envs in shell and in Sublime. That's why I ever tried to solve that in generic way - I tired to "hack" another package which doesn't respect my $PATH.

Sublime Text 4, build 4143.

(Prove otherwise. I can't find any reference it was ever considered to become fixed.)

def read_env(sink): is a bit more modern even) the main change we need is that we should call this per working_dir so it supports multiple projects simultanously open.

I'm not sure I understood you correctly.

we should call this per working_dir so it supports multiple projects simultanously open

Which kind of support do you mean?

No matter how many projects will be open at once, the $PATH will not change - in shell, and in Sublime itself.

def read_env(sink): is a bit more modern even

You should avoid environment mangling as much as you can - that's common source of problems. "Just use shell env, no matter what..." will be perfect motto here. This is what exactly this MR aims to.

I think shellenvs's method is even corporated into newer Sublime Text

There are various bits about this here and there, and it's also long time ago (2018). E.g. sublimehq/sublime_text#1877 and then sublimehq/sublime_text#2390

Basically, Sublime runs something among bash -l which is also what shellenv does (iirc, but it is open source), my #1509 would run bash -il in that case. (Btw shellenv is written by the same author as this Sublime Text feature.)

Generally, there is a setting to turn reading the shell env on/off iirc, and it should print something about it during startup of Sublime.

we should call this per working_dir so it supports multiple projects simultanously open

E.g. nvm will change ENV/PATH depending on the directory it runs on.

You should avoid environment mangling as much as you can

That's probably a misunderstanding, the original PR #1509 does update the global environment (os.environ) but that's exactly the part we don't want and the reason we never merged the PR. We should just read/resolve the env per self.get_working_dir(), and then basically use it like you did here.