Add a configuration setting for a PATH prefix

[erran]

Related to #5, #75, and #93. Adds ability to "shim" the path by prepending a configuration setting if available. Essentially adds a package specific for users to configure their PATHs for this plugin only. It could be extended to pull in other env related parts though.

Configuration:

Running Ruby with and without a path prefix:

[awmartin]

Plus one to this pull request.

[rgbkrk]

Is there a built in that makes sure to pick the right separator for the OS in use?

I've been noticing more and more Win32 related items in Atom internals, so we should be prepped for it.

[rgbkrk]

This is going to prepend path_prefix to process.env.PATH every single time run executes.

[rgbkrk]

The platform specific delimiter is path.delimiter.

[erran]

This is going to prepend path_prefix to process.env.PATH every single time run executes.

I'll look into changing this when I have a minute to site and hack away at this.

The platform specific delimiter is path.delimiter.

I didn't think to look into using a path delimiter vs. :. Assuming *nix is bad though. 😆

[rgbkrk]

path.delimiter is a bit of a misnomer, as it means the delimiter for the environment variable for path not the directory delimiter. 😅

It will use : on *.nix and ; on Windows.

[rgbkrk]

I'm currently a bigger fan of setting your $PATH by opening Atom from the command line or using the init script to add to the path explicitly.

I don't like the idea of putting in side effects that would affect other modules.

[erran]

@rgbkrk The reason I opted for this approach is that the init script will set it for all atom package configurations vs. scoping it to modules in atom-script.

I thought on this last night and think the best solution have a field in the config.cson that mapped to a settings item on the main settings page. As far as I know that's not (yet) possible though.

[erran]

💩 I just realized what you were saying, process.env.PATH would implicitly affect other modules as well. 👎 Closing until there's a better solution. The init script route is definitely the best way right now though.

[erran]

This definitely is something that doesn't belong in atom-script. Regardless, below are a few immediate findings.

Turns out if you add a key under editor/core the main settings page will register that on window reload (or closing and restarting atom):

# ~/.atom/config.cson
'core':
  'PATH': '/Users/ecarey/.rbenv/shims:/usr/local/share/npm/bin:/usr/local/bin:/usr/bin:/bin:/usr/sbin'
  ...
  'projectHome': '/Users/ecarey/repositories'

# ~/.atom/init.coffee
path = atom.config.get('core.PATH')
if path
  process.env.PATH = path

A few possible difficulties with this method:

• Reloading windows, how would that work?
• How does this affect launching from the command line?
• Should we use a PATH_PREFIX instead and prepend it on init?

[rgbkrk]

I like this core approach. Maybe bring it up on the Atom forums and the core devs will pitch in?

This is affecting so many packages.

[ioquatix]

I don't really know if this is helpful but I ended up working around this issue in one of my packages by grabbing all environment variables from the login shell, something a bit like this ended up in the final code:

https://github.com/ioquatix/script-runner/blob/master/examples/environment.coffee

It's interesting to consider whether or not there should be any way to customize this or not. In my package, I do this every time I need to run a script, so that if the user changes anything (e.g. rvm) they'd get the updated settings.

[allenkonstanz]

Mac OS X 10.10.3 solution.

I work around this issue this way:

1- open file .atom/init.coffee and add the code :

fs = require('fs')

#Import ENV from zsh config.
fs.readFile process.env.HOME+"/.zshrc", "utf8", (err, zshFile) ->
  envPaths = []
  for l in zshFile.split('\n')
    if l.substring(0,11) is 'export PATH'
      e = l.split('=').splice(-1)[0]
      e = e.replace(':$PATH','').replace(/"/g,'')
      if ':' in e
        for x in e.split(':')
          envPaths.push(x)
      else
        envPaths.push(e)
  process.env.PATH = envPaths.join(':')

2- open the file .zshrc and add the code (with the path of your groovy/grails included[that's was the case for me adapt to your needs]):

export PATH=$PATH:/usr/local/bin:/opt/local/bin:/opt/local/sbin:/opt/local/bin:/opt/local/sbin:/usr/local/bin/grails/bin:/usr/local/bin/groovy/bin:/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:/opt/X11/bin

3- DONE! Now you don't need to open Atom through the terminal to execute atom-script, you can open atom normally now.

[rgbkrk]

@ioquatix That's pretty neat! Would this correctly pick up any new virtualenvs? It seems like it's only picking up the currently defined variables.

[ioquatix]

@rgbkrk It should do. The functionality was extracted into a npm module: https://www.npmjs.com/package/shell-environment