please contribute that to jupyter notebook

[jankatins]

This would make working with environments so much easier...

[danielballan]

I showed a similar project to @ellisonbg (we should join forces, @Cadair!). He observed, off the cuff, that these kinds of customizations might not necessarily be pulled into jupyter, but that they could inform how to make jupyter configurable -- configurable in a way that customizations them easy to create and to use in combination.

[Cadair]

@danielballan I suspected that this might not be something that would ever get pulled into core.

As far as your conda-kernels goes, I need to look into your kernel spec manager a little closer but it seems like yours uses calls out to the conda executable which makes it conda specific where as mine just looks in a series of directories, which means it works with virtualenv as well as conda.

However, yours uses the default installed jupyter kernel specs, I will look into this, because in theory it's a nicer way of doing it, as oppsed to mine, which dynamically generates the kernel json and feeds it back to the super class.

Does yours show the name of the envronment in the dropdown list?

[danielballan]

As far as your conda-kernels goes, I need to look into your kernel spec manager a little closer but it seems like yours uses calls out to the conda executable which makes it conda specific where as mine just looks in a series of directories, which means it works with virtualenv as well as conda.

I agree. I think a hybrid approach could be really nice. Another difference between your approach and mine is that mine only shows "whitelisted" kernels, specified by the user at any time. Yours shows all kernels by default, allowing for a "blacklist" that must be specified at the time the kernel server is started. Again, allowing for either option would be nice.

Does yours show the name of the envronment in the dropdown list?

Yes. Perhaps unnecessarily, I prefix the name with "ENV: " to signify that the kernel was autogenerated from an environment.

[Cadair]

oh I see, your conda package installs the kernel spec. I missed that the first time I looked at it.

I prefer the approach of not having to install something in the env to have it register (it's better for my orginal use case), but I can see the advantage of having a whitelist of environment names.

I do a similar thing with the name it shows as Environment (NAME), I just didn't notice that was in the conda package in your repo.

[damianavila]

@Cadair (I think we talk sometime in some SciPy in Austin two years ago)
@JanSchulz @danielballan

I did something really close here: https://github.com/Anaconda-Server/nb_conda_kernels

But It is only pointing specifically to conda environments...

Around several months ago I started with an approach writing the kernelspecs for each conda env and then letting the jupyter machinery to take them all... but, when I rewrote the whole thing I found the "ephemeral" kernelspec generation very interesting because of the momentary nature of the conda envs (everyone create then and destroy them because it is easy to do so) and because I don't have to woried about leftovers when I remove the envs...

I just wanted to mention it so you can take a look and use it (or maybe take some ideas about how I detect the environments)

Hope it helps! And nice to be in touch with you again...

Cheers.

[danielballan]

Thanks for sharing this @damianavila. I think that storing the kernelspec in the env, so that it is deleted when the env is deleted, is the way to go. Is that what you mean by "ephemeral"?

[Cadair]

Thanks @damianavila, nice to hear from you again.

Your package looks very similar to this one, we should combine them, seems silly to have many of these things running around.

I can see a few differences:

1. This package can also use VirtualEnvs whereas yours only handles conda envs.
2. You always pop the native kernel. This implies you assume the nb server is always running from inside a non-root conda environment?
3. This package has a few more config options like blacklist / whitelist.
4. You have some kind of install script that I now really want!!

What is your exact use case? You have some install stuff inside your conda package for installing this inside the current prefix?

[damianavila]

Thanks @damianavila, nice to hear from you again.

Sorry for the long delay in my answer... a lot of stuff going on

Your package looks very similar to this one

Yep, I took some of the functions from your codebase 😉 (because they were pretty clear and related with the work I needed to do), changed them and mixed them with my own ones. As I said before, my previous implementation was not creating kernelspecs on the fly... it was writing them, but I think the temporary creation is a nice mechanism for this use case. @Cadair, nb_conda_kernels is BSD but it you want me to reference your license, let me know and I can add it. The spirit of both licenses are the same but I can understand if you want me to add your license as well (I prefer BSD because it is an standard known license instead of customized one). I have an issue opened to reference this repo in the readme for people who wants a virtualenv solution: anaconda/nb_conda_kernels#17

we should combine them, seems silly to have many of these things running around.

And this is related with my previous answer. I do not want to support virtualenvs, this is why nb_conda_kernels is conda-specific... and it handles conda is a different way that you handle it.

This package can also use VirtualEnvs whereas yours only handles conda envs.

Yep, and I pretend to keep it that way... 😉

You always pop the native kernel. This implies you assume the nb server is always running from inside a non-root conda environment?

I pop the native one because I added the root env in the dict containing all the envs...

This package has a few more config options like blacklist / whitelist.

Yep, not interested in those ones for now...

You have some kind of install script that I now really want!!

That's correct, we can talk about that in another issue if you want, but essentially installing the conda package also enable the extension...

What is your exact use case? You have some install stuff inside your conda package for installing this inside the current prefix?

Right now we are using a nb_config_manger: https://github.com/Anaconda-Server/nb_config_manager a custom config manager I wrote to enable the nbextensions in prefix...
But regarding nb_conda_kernels, the installation/enabling in prefix is handled with a post-script thing inside the conda recipe: https://github.com/Anaconda-Server/nb_conda_kernels/blob/master/conda.recipe/post-link.sh referencing this install/enable script: https://github.com/Anaconda-Server/nb_conda_kernels/blob/master/nb_conda_kernels/install.py

Let me know if you want to know more!

[theredpea]

Interesting to learn the history of jupyter_environment_kernels vs nb_conda_kernels , I came from this Stack Overflow question