Reference jupyter_environment_kernels for virtualenv people
A closely related work lives here: https://github.com/Cadair/jupyter_environment_kernels
They support virtualenvs (also conda but is a different way). We should mention them in the README so people using virtualenvs can achieve the functionality...
After https://github.com/Cadair/jupyter_environment_kernels/pull/6, this looks like almost the same :-)
The main problem I had in that PR is how to really activate an env: https://github.com/Cadair/jupyter_environment_kernels/pull/6#issuecomment-185314673
The problem is that activate env can potentially add dirs within the env to the PATH and this is not the same as simply running /full/path/to/python.exe. I'm also not sure if the Script dir (and whatever it is on linux) is in the search path for commands, so installing pandoc (which is in the conda-forge channel) or things like convert.exe and ffmpeg.exe (e.g. used for matplotlib animations; AFAIK not yet packaged) will be found :-/
Interesting dilemma... I have to think a little bit more about this. Thanks for the feedback, it is pretty useful for further development.
Just FYI: https://github.com/Cadair/jupyter_environment_kernels/pull/13 contains a version which activates an environment and uses the environment variables as hey are after activating to start the kernel.
Thanks for the reference, I just did a quick overview and look as a nice compromise including xonsh source to have the reference you are interested on... I will take a look more in depth, for sure! Thanks again!
Just a question: would you e willing to take patches to make it work with virtualenv? I really like the functionality this (and Cadair/jupyter_environment_kernels) package provides, but I would like to not waste effort to develop both versions: this one has tests, but Cadair/jupyter_environment_kernels has virtualenv and real activate support.
@jankatins now that #80 is merged, maybe we should revisit this. I'm happy to accept a PR to add language to our README.md.
@jankatins FYI I've tagged a 2.2.0 release here; perhaps you can examine the current state of the code and determine if a clean PR is feasible.
Closing as stale but would still accept PRs for this or other improvements!