That very much sounds like a bug. Is there any output, or just nothing? Can you take a look whether there is a folder named ~\.julia\juliaup and if there is anything in there? It would be enough to let me know what files are in the folder and if there are any subfolders. If there is a json file in there, could you post the content of that here?
Could you also show the output of juliaup status and what that shows?
Oh, and ideally could you provide all that info over in an issue at Issues · JuliaLang/juliaup · GitHub? Probably better to try to resolve that over there than here in the thread.
I am using juliaup only to manage the installations which works well. It would be nice to have a way to get the direct binary path with a command, because I would rather not have the small julialauncher.exe program running.
And I just tested it on a Windows on ARM machine, and it also just works. Of course it won’t install an ARM build of Julia because there is none for Windows, but instead it installs the x64 build and at least on Windows 11 that seems to work with emulation.
So I’ve been mulling over that… I was actually hoping to keep the “true” location of these binaries an implementation detail, and ideally have third party apps that want to integrate always run via the julia command. But that of course does imply the small julialauncher.exe is running. That program is very minimal and written in C++, so hopefully it should not introduce much overhead at all. Did you find it to be slow or some other problem?
Here is my Juliacon talk about Juliaup. There really isn’t anything new in there beyond what I’ve written here already, but if you are too lazy to read (really??) you could watch it
Thanks for the great experience! I think I’m one of the 61 early adopters, and so far the julia installation is far better experience, than doing it manually. In particular I hated changing the PATH variable and restarting the console (or often my machine) to get the new version…
A few remarks, that have been discussed already or there’s open issue:
It would be nice to have the logo in the Windows Terminal profile. (I suppose #30 is related).
First time I was also confused by the julia name in the store, because I was searching for juliaup, and the description doesn’t say too much about which version will be installed or the relation with juliaup.
These are small remarks anyway, I mainly just wanted to say thank you!
This is actually an upstream problem, see here. I’m sure likes on that issue would help prioritize it
Ah, that is a good point, we should make sure that juliaup is something like a keyword and in the description!
I think that option works pretty well for a one-time setup, but once one starts to install multiple Julia versions on a system or updates or something like that, the solution from the store installer starts to really shine because it explicitly handles those scenarios as well.
You can set it on your own by adding e.g.: "icon": "...your_path_to...\\julia.ico",
to the settings.json .
(I am not allowed to upload to file julia.ico, sorry).
Thanks, this is heroic stuff, just what I’d beeen hoping for.
Only problem I’ve found is when trying to run Jupyter notebooks in VSCode. I uninstalled my old Julia before installing the new one from the Windows store. In the VSCode Julia extension settings I deleted the old executable path and it found the new one, allowing me to run regular Julia code within VSCode. But when I open a Jupyter notebook within VSCode it asks me to select a Julia kernel but only offers the old, uninstalled ones as choices. How do I point it to the new one?
Are you sure that you enabled the notebook support in the Julia extension? There is a configuration setting that switches it on called julia.notebookController. One other thing I still need to fix is that the notebook support in VS Code does not yet show all the versions of Julia you installed as kernels, at the moment only your default Julia from juliaup will show up as a kernel in VS Code.
Not at the moment, but I think we have a roadmap now to enable that. I rewrote juliaup in Rust last week, and now we can compile and run it pretty much on any platform. There are still a lot issues that we need to resolve before this is ready, but the plan now is very much to make this available on all platforms, not just Windows and the Windows Store.
I tried to use the Windows Store installer on my home computer. This is what I did:
Uninstalled Julia, Python, etc. via the Control Panel. I kept VScode on my computer.
Used FileExplorer to remove all I could find related to Julia, Python, etc. Also in %appdata%
Downloaded the Julia app from Windows Store. Worked smoothly.
I then opened VScode and added the Jupyter notebook extension from Microsoft.
OK – now, VSCode uses the latest version of Julia in the terminal window (v. 1.6.2). However, when I try to run Jupyter notebook, VSCode tries to find the old version of Julia I had on my computer (1.6.0, I think), and gives an error message when it doesn’t find that version.
So – apparently, there is something referring to Jupyter version that I didn’t delete… Any ideas of where that file is found?
You still have an IJulia.jl kernel registered. They don’t go away when you delete or uninstall Julia, you would have to manually delete them.
The VS Code Jupyter extension is surfacing these IJulia.jl kernels (which in your case are still registered but don’t actually exist anymore). To use the new native notebook feature in VS Code you need to enable that in the settings for the Julia extension, and that should then show a new kernel that is the Julia version you installed from the Store. That kernel is “registration” free.
