<h1 dir="auto">Problem</h1>
<p dir="auto">Various tools don't operate correctly depending on the order and the manner with which Atom is started.</p>
<p dir="auto">Also, persisted state is not restored consistently.</p>
<h1 dir="auto">Cause</h1>
<p dir="auto">Depending the manner in which Atom is started, a different environment is inherited.</p>
<ul dir="auto">
<li><strong>launchd event</strong>: inherits launchd mostly blank env, which means no shell env vars</li>
<li><strong><code class="notranslate">atom</code> in the terminal</strong>: inherits currently set vars</li>
</ul>
<p dir="auto">This applied to when the app is <em>started</em>, not when a new window is opened, in which case that window will inherit the current process env (which is normal OS X behaviour)</p>
<p dir="auto">I venture the creation of the <code class="notranslate">atom</code> command this way is on purpose to work around the lack of env when run from launchd. But please, dear reader, continue on to the next step.</p>
<h1 dir="auto">Current workaround / Anti-feature</h1>
<p dir="auto">Manually control Atom startup each time you want to use it in a specific environment.</p>
<p dir="auto">Why is it an anti feature? If you want two projects open at the same time but with different environments, you're busted.</p>
<p dir="auto">Also, long running sessions and <em>"wait what env was that started with already?"</em> (session can also mean the idiomatic "document != app" OS X way: "Atom.app is started but no windows are opened") .</p>
<p dir="auto">Also also, frustration quickly sets in when you start it up the wrong way and have to quit and restart halfway through your work and notice your linter does not actually run (manual config does not cut it because 1. it's manual and 2. constantly changing versions means constantly changing path).</p>
<h1 dir="auto">Possible solution</h1>
<ol dir="auto">
<li>wrap Atom.app startup in a login shell (i.e make <code class="notranslate">Atom.app/Contents/MacOS/Atom</code> a script that calls whatever the user shell is† as a login, non-interactive one before calling the real <code class="notranslate">Atom</code> binary), to inherit global env, so that chruby/rbenv/GOPATH/whatever works.</li>
<li>make <code class="notranslate">atom</code> command send a signal to <code class="notranslate">Atom.app</code> instead of starting atom itself via <code class="notranslate">Contents/MacOS/Atom</code>. Basically, <code class="notranslate">atom foo/bar</code> has no reason to be different from <code class="notranslate">open -a Atom foo/bar</code>. <del>Precisely, it <em>does not</em> inherit the local environment.</del></li>
<li>local environment management is bestowed to package implementor (meaning detection of <code class="notranslate">.git</code>, <code class="notranslate">Gemfile</code>, <code class="notranslate">.rubocop.yml</code>, <code class="notranslate">.gopath</code>, which they have to do anyway else at least starting via launchd is broken, if not more), not to manual handling by developer.</li>
</ol>
<h1 dir="auto">Consequences</h1>
<ul dir="auto">
<li><code class="notranslate">PATH</code> &amp; al. is properly set and tools like linters can leverage the env to use chruby/rbenv/whatever.</li>
<li>Clicking the icon, starting via spotlight, opening a file from Finder, using <code class="notranslate">open -a Atom</code> and using <code class="notranslate">atom foo</code> on the terminal are all consistent, whatever the order they are executed in.</li>
<li>Everything is now consistent and we can now rejoice as glittery roses spontaneously bloom out of Bose-Einstein condensates.</li>
</ul>
<h1 dir="auto">Additional note</h1>
<p dir="auto">Pet peeve: <code class="notranslate">atom</code> is currently equivalent to <code class="notranslate">atom .</code>. While I can see how this could be ok on other platforms, this is subtly wrong on OS X as <code class="notranslate">atom</code> is expected to be equivalent to <code class="notranslate">open -a Atom</code>, i.e start the app and don't open anything (unless it's set up to open a new document when no document is opened, otherwise merely focus the app, and if the app is not started, start it)</p>
<p dir="auto">On another planet, I don't know if this issue applies to other OSes as well besides OS X. Everything depends on how process management and app/doc/task GUI model is handled there.</p>
<h1 dir="auto">Final word</h1>
<p dir="auto">All of this really matters daily when you juggle between projects and makes Atom feel like an unfinished, brittle product, making angry coworkers throwing nails at me for having pushed Atom on them.</p>
<p dir="auto">† think fish-shell or (god forbid) csh.</p>
<p dir="auto">When Atom is launched as an application, it doesn't get the user's PATH, because it was launched by <code class="notranslate">launchctl</code>. This means that packages like <a href="https://github.com/rgbkrk/atom-script">script</a> and <a href="https://github.com/willwhitney/hydrogen">hydrogen</a> have to tell the user to launch Atom from the command line. Some packages (like hydrogen) can't even be installed without the PATH because their dependencies use native extensions built with <a href="https://github.com/TooTallNate/node-gyp"><code class="notranslate">node-gyp</code></a>. There exist tools such as <a href="https://github.com/sindresorhus/fix-path"><code class="notranslate">fix-path</code></a>, but they clobber the user's PATH even if they've set something on purpose (with e.g. a virtualenv).</p>
<p dir="auto">Having access to the user's PATH will become more and more important as people build packages that interface more deeply with languages, other tools, and the user's environment. Forcing the user to configure each package with complete paths to the binaries it needs is possible, but inelegant, and becomes intractable with general-purpose tools.</p>
<p dir="auto">This seems like a clear situation where making this change to Atom itself would dramatically simplify life for many packages and eliminate many bugs arising from poor attempts to capture the PATH.</p>