Merge with master and fix test_api.py

[echarles]

this branch resolves:

• the current merge issue with master on jupyter_server/services/kernels/handlers.py
• fix compilation issue on NATIVE_KERNEL_NAME on tests/services/kernels/test_api.py

On my local env, test_api.py is failing with jupyter_kernel_mgmt.kernelspec.NoSuchKernel: No such kernel named python3

[kevin-bates]

Hmm - the appveyor issue is odd. It's unable to update jupyter_core as best as I can tell. ??

[echarles]

yep, only failing py35 on appveyor due to a permission while installing libs. I don't see any way to retrigger the appveyor build apart from pushing a fake commit.

[kevin-bates]

In comparing your branch with the rebase/master that I'm working on, I see that yours doesn't include this commit: jupyter-server@0d67d5d

[echarles]

true, I realize I didn't pull the very latest master. Now latest is merged. Let's see what appveyor says.

[echarles]

Strange... Only on PY35. Should we install with ---user?

ERROR: Could not install packages due to an EnvironmentError: [WinError 5] Access is denied: 'C:\\Users\\appveyor\\AppData\\Local\\Temp\\1\\pip-uninstall-7v3f2fm2\\jupyter-migrate.exe'
Consider using the `--user` option or check the permissions.
Command exited with code 1

[kevin-bates]

Have you confirmed that the other python versions pass? All I see is that they were cancelled. Perhaps removing 3.5 from the list (temporarily) would provide a good datapoint before introducing --user. But if 3.5 is the only one failing, then I would agree - although I'm not python-savy enough to understand all the ramifications about that.

[echarles]

True, other than 3.5 are cancelled. Note the windows on github actions succeed. Would it be a temporary issue with appveyor? Let's have a look tomorrow and maybe also how the other PRs behave.

[kevin-bates]

Hi Eric - I ran a couple experiments using PR #2. If I remove 3.5 from the appveyor matrix, the other pythons pass. I suspect the underlying issue is due to the initial jupyter_client install (that occurs when the conda env is created) is installing jupyter_core 4.5.0. But JKM wants jupyter_core 4.6.x, so when installing Jupyter Server, it goes to cleanup jupyter_core 4.5.0 and, for whatever reason, runs into the issue with jupyter-migrate (which is an application from the core package).

Seems like we should decide if we're bailing on appveyor (and travis?) in favor of GH actions. Or we could simply remove 3.5 from the appveyor matrix, knowing that Windows 3.5 is tested via GH actions.

[echarles]

I usually do like putting all the eggs in the same basket, but in this case IMHO github actions is reliable enough to remove appveyor and travis. They have given more disavantages than advantages so far.

I had already opened jupyter-server#148 to remove travis. We can continue the conversation there and see if there are any objection for that.

[echarles]

Merged with latest master and build is still green (you can forget about appveyor which has been removed).

[kevin-bates]

Thank you Eric! I'm really sorry I've haven't had the time to give this proper attention.

[echarles]

@kevin-bates Closing as discussed. We will rebase on master later.