Support Windows

[monkpit]

There are several issues preventing this package from running on Windows.

The most noticeable is the fixPath() function that runs when the package starts - this has the side effect of completely breaking any other package that relies upon your PATH variable, like linters, compilers, etc. I can't tell what it is actually trying to fix, or I'd submit a pull request with a patch.

I would suggest not relying upon hard-coded path separators like .split(':') - use require('path').delimiter instead.

In notebook-editor.js, I would try to avoid relying upon lsof -i:${port}, as this is not a portable command.

That's just a few observations, I can't get kernelgateway to get called from atom-notebook correctly so I can't even run the package after making changes. A setting to define where my jupyter-kernelgateway or base jupyter binaries exist would be nice.

[gnestor]

Thanks for bringing this to attention.

1. The problem is that Atom packages do not inherit the full user PATH if Atom is not launched from the command line, so we see errors like: 'node' could not be spawned. Is it installed and on your path? If so please open an issue on the package spawning the process. fixPath was inspired by fix-path npm module and simply adds the default paths (for OS X at least) back to the process so that it can spawn other processes without running into this error. I admit that this solution should not add hard-coded paths but instead add the user's PATH (e.g. using echo $PATH). @monkpit does PATH work similarly on Windows? If you would like to submit a PR that would be appreciated.
2. What command would you use on Windows to see what if/what process is running on a specific port?
3. The reason for fixPath above is to set the process PATH so that it can run commands like jupyter and jupyter kernelgateway. If the command is available in one of the paths, then it should work.

[monkpit]

What is the value of process.env.PATH when node is not launched from the command line? In Windows, process.env.PATH will be your system path when the program is launched through the Explorer.

There may be a sanity check to say, fixPath only runs if process.env.PATH == null or something like that. That way, on Windows it should never run.

Regarding 2., a quick google search brings up netstat -na | find /i "listening" to list all processes listening on the machine. There may be some permission conflicts here regarding whether a user can see a process being run by another user or administrator.

Sample output looks like so:

  TCP    0.0.0.0:80             0.0.0.0:0              LISTENING
  TCP    0.0.0.0:111            0.0.0.0:0              LISTENING
  TCP    0.0.0.0:135            0.0.0.0:0              LISTENING
  TCP    0.0.0.0:445            0.0.0.0:0              LISTENING
  TCP    0.0.0.0:2701           0.0.0.0:0              LISTENING
  TCP    0.0.0.0:3306           0.0.0.0:0              LISTENING
  TCP    0.0.0.0:4445           0.0.0.0:0              LISTENING
  TCP    0.0.0.0:5432           0.0.0.0:0              LISTENING
  TCP    0.0.0.0:5985           0.0.0.0:0              LISTENING
  TCP    0.0.0.0:6002           0.0.0.0:0              LISTENING
  TCP    0.0.0.0:7001           0.0.0.0:0              LISTENING
  TCP    0.0.0.0:7002           0.0.0.0:0              LISTENING
  TCP    0.0.0.0:9217           0.0.0.0:0              LISTENING
  TCP    0.0.0.0:17500          0.0.0.0:0              LISTENING
  TCP    0.0.0.0:30950          0.0.0.0:0              LISTENING
  TCP    0.0.0.0:47001          0.0.0.0:0              LISTENING
  TCP    0.0.0.0:47546          0.0.0.0:0              LISTENING
  TCP    0.0.0.0:49152          0.0.0.0:0              LISTENING
  TCP    0.0.0.0:49153          0.0.0.0:0              LISTENING
  TCP    0.0.0.0:49154          0.0.0.0:0              LISTENING
  TCP    0.0.0.0:49193          0.0.0.0:0              LISTENING
  TCP    0.0.0.0:49789          0.0.0.0:0              LISTENING
  TCP    0.0.0.0:49790          0.0.0.0:0              LISTENING
  TCP    0.0.0.0:57824          0.0.0.0:0              LISTENING
  TCP    0.0.0.0:65343          0.0.0.0:0              LISTENING
  TCP    127.0.0.1:843          0.0.0.0:0              LISTENING
  TCP    127.0.0.1:3142         0.0.0.0:0              LISTENING
  TCP    127.0.0.1:5354         0.0.0.0:0              LISTENING
  TCP    127.0.0.1:8745         0.0.0.0:0              LISTENING
  TCP    127.0.0.1:17600        0.0.0.0:0              LISTENING
  TCP    127.0.0.1:23402        0.0.0.0:0              LISTENING
  TCP    127.0.0.1:27015        0.0.0.0:0              LISTENING
  TCP    127.0.0.1:57433        0.0.0.0:0              LISTENING
  TCP    [::]:80                [::]:0                 LISTENING
  TCP    [::]:135               [::]:0                 LISTENING
  TCP    [::]:445               [::]:0                 LISTENING
  TCP    [::]:2701              [::]:0                 LISTENING
  TCP    [::]:3306              [::]:0                 LISTENING
  TCP    [::]:4445              [::]:0                 LISTENING
  TCP    [::]:5432              [::]:0                 LISTENING
  TCP    [::]:5985              [::]:0                 LISTENING
  TCP    [::]:9217              [::]:0                 LISTENING
  TCP    [::]:47001             [::]:0                 LISTENING
  TCP    [::]:47546             [::]:0                 LISTENING
  TCP    [::]:49152             [::]:0                 LISTENING
  TCP    [::]:49153             [::]:0                 LISTENING
  TCP    [::]:49154             [::]:0                 LISTENING
  TCP    [::]:49193             [::]:0                 LISTENING
  TCP    [::]:49789             [::]:0                 LISTENING
  TCP    [::]:49790             [::]:0                 LISTENING
  TCP    [::]:65343             [::]:0                 LISTENING

Then to check similar to lsof -i${port}, maybe just combine another find command in there:

netstat -na | find /i "listening" | find /i "${port}"

So from my output before, if port=80 the output is:

  TCP    0.0.0.0:80             0.0.0.0:0              LISTENING
  TCP    [::]:80                [::]:0                 LISTENING

and if port=8888 the output is blank.

[gnestor]

It seems like the path issue only affects OS X, so I put this inside of a conditional. I also switched from using lsof to netstat. Can you try clone the fix-path branch, apm install, apm link and test on Windows before I push to master? (Be sure to 'apm unlink' afterwards to continue using the version managed by Atom).

To answer your question, the process.env.PATH that is available when launching any app from the Dock, Finder, Spotlight, etc. (any way other than command line) on OS X appears to be usr/bin:bin:usr/sbin:sbin which doesn't include usr/local/* where many binaries are located including jupyter. I'm surprised this hasn't been patched in atom-core yet, but we can patch it in the package by simply adding these default paths back to process.env.PATH.

[gnestor]

Just published 0.0.5. Update and let us know what happens...

[monkpit]

Sorry for the late reply, I don't always have access to my windows box.
The fix you submitted works for me, I can keep my path variables after loading jupyter-notebook.