Set kernel name for notebooks with papermill about abc-classroom

[betatim]

papermill -k python3 is the command to use. The question is: do we need to look at the name of the kernel in the notebook we want to run to figure out what version of python the author really meant?

Another question is what will happen on a student's computer where they don't have the conda notebook extension installed that gives them kernels with these environment specific names? Should we be "cleaning" the kernel name in a notebook when we distribute it instead of telling papermill what to use?

[betatim]

What do you think of the option of cleaning the kernel name when we run nbdistribute @lwasser? I think that is my favourite option at the moment.

This means that either on the nbauthor or nbdistribute step we'd check what kernel name is in a notebook and if it is "something weird" we set it to python or R without the appendage you get from using sth like the conda environment manager extension (not sure what exactly it is called). This way instructors can keep their workflow and for students (and the grading bot) things are simple.

[lwasser]

sure thing @betatim may i ask what weirdness you are seeing? it is something in the json that it adds?
i'm fine with ensuring it just says python. it doesn't matter because it will run in whatever environment it's given for us (that's how i understand it anyway)!

I have thought about removing that kernel package (nb_conda_kernel) i think is what it is called. The nice thing about it is it helps with tools like atom to connect the correct kernel (i think??). I had a few students struggling with this. However for me, just launching notebook from the active envt solve the issue of needing to select a kernel in the notebook. So i've considered removing it from our environment as well.

[betatim]

sure thing @betatim may i ask what weirdness you are seeing?

The problem is that on CircleCI we don't have a kernel with exactly the name given in a notebook if you use nb_conda_kernel.

I have thought about removing that kernel package

I don't have much experience with that package. I do what you do, activate the environment and then type jupyter notebook in that terminal. This "just works" in terms of selecting the right Python kernel.

The nice thing about it is it helps with tools like atom to connect the correct kernel

I know with nteract.io we have had some fun figuring out what exactly happens and I think it is the same with atom. My understanding: if you click "Atom" in the Applications menu in your dock it will get no conda environment set. I think it gets launched without most of your .bash_rc being executed.

If you launch Atom from the command-line (without first starting it from the Applications menu), something like atom . then it gets the settings (and kernel) from that terminal. Like when you run jupyter notebook.

Now is where the fun starts: if you start Atom from the Applications menu, leave it running and then run atom . from a terminal you won't get that terminal's environment! What counts is the first time you launch Atom. Same if you properly close (exit the app, not just close all windows) and then launch it from the terminal. All future launches of Atom will use the environment configured in that particular terminal (when you first launched Atom).

This seems to be a "feature" of OSX and effects Nteract as well. So yeah, I think the only summary is "it is complicated" and then something something about how it all makes sense if you think like a OSX designer.

[lwasser]

Ahhhh this makes so much sense. I don't know why i never thought about launching atom from the CLI with the envt active. I get generally how it works. So many "nice features" to work around :) ha!
Well this sounds great. If a clean of the notebook will make life easier, let's do it. if that package becomes too cumbersome to our workflow please let me know and i'll dig into it more.