Uncaught Error: spawn ENOENT

[szimek]

This error happens when path to rubocop binary is missing or invalid. I installed a few packages at the same time and it took me a while to find out which one was causing this error. Wouldn't it be possible to throw some more detailed error message if rubocop binary can't be found?

[soupmatt]

I am having the same issue. I am using rbenv, and I kept getting this error until I installed rubocop in the system ruby.

[rogernordqvist]

I'm using RVM and getting this problem. Spawning atom from the same shell as rvm is being setup in. Is this by design, will it ONLY work with system wide ruby installations?

[szimek]

@rogernordqvist I'm using RVM as well and Rubocop Executable Path like this works just fine:

/Users/szimek/.rvm/gems/ruby-2.1.2/bin

[olafurg]

Is there a workaround for this? I'm having the same problem. I use RVM and when running which rubocop I get a proper response.

[szimek]

@olafurg It works fine for me with RVM. which rubocop returns /Users/szimek/.rvm/gems/ruby-2.1.2/bin/rubocop and setting Rubocop Executable Path to /Users/szimek/.rvm/gems/ruby-2.1.2/bin works fine.

[hd-deman]

for rbenv users: run rbenv which rubocop

[olafurg]

Thank you @szimek. I missed the part about setting the executable path in config.cson. Now it's working fine.

[mindvox]

If I place '/home/karlbateman/.rvm/gems/ruby-2.2.3/bin' within my config.cson to workaround this issue, I receive the following error:

Any updates on what maybe causing this?

[steelbrain]

@karlbateman if I had to guess, your rubocop is too old.

[mindvox]

@steelbrain v0.34.2

[krainboltgreene]

So I think I divined why this is happening, at least for me:

I was opening atom faster than rvm could switch to the right gemset.

[Arcanemagus]

@karlbateman if you haven't already figured this out, you placed a directory in the executablePath, instead of the required full path to rubocop.

I'm marking this as closed since this is a user configuration issue and not a problem with the package itself.

[krainboltgreene]

@Arcanemagus I hate to say this, but I think there is a problem with how the package functions. I was wrong before. I'm opening atom in a directory with rvm setup, and every time I do I get the ENOENT error. I have no idea why. Everything is correct, and sometimes it works.

[krainboltgreene]

I'm able to reproduce it specifically now. It here's the process for getting it to work:

1. Have no atom instances open already.
2. Open a terminal.
3. Use atom .

This works. Now for how to reproduce the error:

1. Have an atom instance open already, so far tested by targeting another repository
2. Use atom .

Now you're screwed. Even if you close this window project and reopen it with atom . you'll still get the error. It's not until you reopen atom and you open this project first does it work.

[krainboltgreene]

I suspect it's the difference between:

https://github.com/AtomLinter/linter-eslint/blob/master/src/worker.js#L33-L52

and

https://github.com/AtomLinter/linter-rubocop/blob/master/index.coffee#L27

[Arcanemagus]

@krainboltgreene rubocop and eslint are two entirely different programs, and don't even run in the same manner.

rubocop depends heavily on the environment it is ran under to resolve the proper gems, and even the version of ruby that it is running under. Quite often the issue is that the user is using rvm and tries to use one of the rvm scripts (which depend on shell macros that don't work outside of a shell) directly without creating a wrapper script. Or they are trying to use more than one different version of ruby / some dependency through rvm and fail to understand that once Atom has been launched, the environment is essentially set. We do some workarounds for OS X since Apple starts GUI applications with a blank environment, but that's it. There is some initial talk of project specific environment support in Atom, but it's a long way off.

Your "error case" there is a case of the latter where you are expecting the environment to match what you are in when you launch atom . again, but as it is already open it keeps the original environment.

eslint on the other hand is a Node script, and runs from within Atom's Electron engine itself, we have to do some trickery to determine which eslint to run (project local, global, or embedded in the package), but the environment it is ran under has essentially nothing to do with that.

[krainboltgreene]

Excuse the previous two comments, for me this is a pretty annoying result of what should be essentially the same two adapter pattern packages doing pretty much the same exact thing. Somehow the eslint version seems to be getting special treatment because electron happens to be a JS environment.

[Arcanemagus]

Node modules are by design completely self contained, with their dependencies guaranteed to be part of them (or in newer smarter Node versions, at the same level as them). Ruby gems depend on their dependencies to be installed on the system, and able to be found via the environment.

The two models of dependency are entirely different. With Node it's relatively simple since all you need are file paths and once you have the base path figured out the rest is (relatively) easy to do. Figuring out the base path can be a bit tricky, but that's a different story.

Ruby gems though depend on the environment they are ran under to determine what is available to them instead of the file paths that things are located at. rvm wouldn't work without this as manipulating that is how it works. The issue comes when you try to launch two different projects with two different expectations for how things should be, since Atom runs with a single application model, once it is first launched the environment is set. You can essentially only use Atom for one rvm enabled project at a time.

I'm barely even a beginner with Ruby though, so I could be completely misunderstanding things and would absolutely love to be corrected since I simply don't know for sure. This is just how I see it from the myriad of issues people have filed on Ruby related projects. Python projects have a similar set of issues, as normally their dependencies are resolved via the environment as well (virtualenv doing similar things to rvm), however the dependencies there are often installed into a single directory, and several of the Python linters have added support for filling in parts of the paths to their tools with the current project's path. Maybe something like that would work for the Ruby projects?