we just released version 1.3 of the Julia extension for VS Code, which brings a bunch of new features:
Experimental native Jupyter notebook support. With this feature you can work with Jupyter Notebooks by just installing the Julia and Jupyter extension in VS Code. You don’t need IJulia.jl or Jupyter itself anymore. The entire setup is configuration free, so hopefully it will prove to be easy to install and maintain. There is one known bug with our current implementation: we are not saving kernel information into the notebooks that you save. Because of that, we are “hiding” the notebook support behind a feature flag in this release and you have to opt-in to use it: simply set the configuration value for julia.notebookController to true and everything will work. We are waiting for a new upstream API to resolve this issue, as soon as that ships we will enable the notebook support for everyone by default. We are demoing the new notebook feature in our Juliacon talk today here.
One of the most dreaded UI elements of the Julia extension is the “Indexing packages…” status bar item. The good news is that we made great progress on getting rid of this entirely in this release. We now try to index the entire general registry in the cloud, store the pre-indexed information in the cloud and the Julia extension will now first try to download the index information. If that doesn’t work, it will fallback to local indexing, as it has done in the past. We hope that this will significantly reduce the need to index anything on local machines. Once we have a bit more real world data about this approach, we hope to eventually turn of local indexing entirely.
As always, feel free to post issues over at the julia-vscode repo and enable crash reporting if possible – it really helps tremendously with providing a stable extension.
I just had to try the julia.notebookController thing - and it seems to work. That’s great. Thanks a lot. This will be a good alternative to nteract.
I did notice that you apply the REPL scoping rules. Maybe that’s something you have decided on already. If not, please consider the SoftGlobalScope.jl as a default. I guess that is what julia.ipynb users have become used to.
(Personally, I don’t mind the REPL rules, but my students clearly prefer those in SoftGlobalScope.jl
This is an exciting announcement! Thanks very much for the new release. One question:
When you say that local indexing will be turned off entirely, what does that mean for packages that are private or just not in the General registry? Will they still be indexed locally or could they just not be indexable in the future? If I understand correctly, indexing a package is required for full linting support and for handy features like autocomplete and hovering over a function to get the docstring. It would be a shame to have those capabilities only available for code in packages from the general registry.
Our current plan (a bit in flux, though) is to run our normal static analysis on deved packages. That in general has a much harder time to pick up everything correctly, in particular in cases where you use a lot of meta programming and other “wild” things. On the plus side, it can pick up changes much quicker as you edit.
We haven’t thought much about the private registry scenario… Maybe we should just keep the local indexing around for that.
Thanks for the reply. I have no idea of the trade-offs involved in maintaining the local indexing but for me personally and for colleagues at my company, the ability for the vscode julia extension to work seamlessly with private packages is really helpful. I’m not sure how widely private registries are used but a quick search turns up a decent number of discourse topics. Seems to be useful not just for keeping things private but also for folks who just don’t want to use the general registry, for whatever reason. I know of at least one academic group that maintains their own registry of publicly available packages.
Yes. “Normal static analysis” is parsing your files and what happens for any non-package code. Indexing loads a package and asks the runtime which objects it defines.
I’ve set julia.notebookController to true, but when I open an .ipynb file I still just see plain text - is there anything else I have to do to try this feature?
I didn’t - I was under the impression that this feature was dependency-free, but I guess it does make sense that VSCode should at least have the basic ability to open notebooks!
I can display the notebook now, but I can’t seem to run anything, the extension says Failed to find a kernelspec to use for ipykernel launch.
When I tap the Busy button on the top right, I get a list of kernels, which includes all the kernels I had already installed through IJulia in the past. What I don’t have is a 1.7.0-beta3 kernel, which is the Julia version I currently use in VSCode. Do I need to add the kernel manually through IJulia? I guess not given that the VSCode extension should be useable without IJulia from what I understand?
I installed the 1.7.0-beta3 kernel from IJulia, and restarted VSCode. I think the problem was that the default kernel that VSCode selected was a 1.6.1 kernel, but I uninstalled 1.6.1 when 1.6.2 was released so it didn’t exist. Maybe an unexpected side effect of existing IJulia installations on the new notebook feature?
There’s something funny about tab completions - they all show these blue boxes:
and don’t work, hitting tab will just close the suggestion list and I’m left with \in. Switching to a tab with a regular jl file in the same VSCode instance:
It should at least show the one julia.executablePath points to (although I think you need to restart VSCode to re-populate the kernel list). Does a normal REPL work for you?
Yes, although it doesn’t start if I do stuff in the notebook only (which makes sense I suppose given that apparently my kernel is an IJulia, not VSCode kernel!)
