Enable default kernel so no needs to use *.ju.* file
MathisClautrier opened this issue · comments
I think it would be great to give one the opportunity to use jupynium without using a suffix like .ju. (for lazy users). I started working on it (as I am using remote-local, I could only work on jupynium as a python package rather than an installed nvim plugin, but I don't think it is relevant here).
As this default kernel would be user dependent I think it should be defined in ~/.jupynium/preferences.yml with a line like:
default_kernel: 'python3'
Thus multiple users of a single venv could define different default kernels. Then, we would override the found kernel_name (when processing start_sync) by reading this yaml file (if the default_kernel is defined). The advantage of such solution would be to reuse this yaml file for other customization (like replacing the percent syntax by anything).
I've implemented a potential solution but I struggle a bit on the following:
If I launch jupynium with a nvim editing test.txt it works fine, but if I close it and re-open another file, this file is ignored unless it follows the ju. syntax. (I can see, in the first case, that the file is not added to the queue as https://github.com/kiyoon/jupynium.nvim/blob/master/src/jupynium/cmds/jupynium.py#L556 is consistently empty). I couldn't find why this happens though.
Let me know if this solution would be acceptable for you and if you know what is blocking me above so I can raise a PR for it,
Thanks!
I think it would be great to give one the opportunity to use jupynium without using a suffix like .ju.
The reason *.ju.* convention exist is that neovim needs this information to activate Jupynium's syntax highlighting and other features. You can change this convention if you want, in the setup. (e.g. set it to *.py and it will work for all python files).
As this default kernel would be user dependent I think it should be defined in ~/.jupynium/preferences.yml with a line like:
-
Jupynium automatically detects the current conda or venv environment and try to find the right kernel that matches the
$CONDA_PREFIXor something equivalent in venv. This only works correctly if you're using it locally, though, because the remote environment may have a different conda setup. I'd suggest you to follow the conda/venv installation as equally as possible in both remote and the local machine. For example, if you install conda in the same path, and give the environment name equally, it will be able to detect the correct environment and it will activate it. -
The potential problem of introducing the preferences file is that there are users who use neovim setup, and there are users who use the python CLI directly. If you use it through neovim setup, all the setup in the preferences file will be ignored, confusing users. If you don't mind, you can maybe make a bash script wrapper or aliases that calls Jupynium in the customised way you want.
Hello,
Thank you for this detailed answer,
I forgot to mention the question of the $CONDA_PREFIX in the feature request, but enabling a default kernel would be to override this behavior in the following context:
- Multiple users use the same virtual env
- Half of them are using Python, the other half is using R,
About your second point:
The potential problem of introducing the preferences file is that there are users who use neovim setup, and there are users who use the python CLI directly. If you use it through neovim setup, all the setup in the preferences file will be ignored, confusing users.
In the case of the default kernel, the behavior wouldn't apply for both type of users as the change will be in the function and not in the call of it? If not, we can still enable the option for neovim setup as well so that it doesn't confuse the users in the end, what do you think?
I think a better way would be to add :JupyniumKernelChange [kernel name] command which wouldn't show a kernel list but it just changes kernel given the name of it. Then you can just add a keymap yourself that calls :JupyniumStartSync and :JupyniunKernelChange together. This way is cleaner than adding yet another dotfile.
I think it is a great solution, I am working on it
Note that there is already an unofficial lua function that does this.
Jupynium_kernel_change(bufnr, kernel_name)There is no :JupyniumKernelChange command though. You can try this and let me know if it works?