Microsoft Store binary install path conflict with VS Code

[vAdalid]

I updated yesterday my Julia from 1.9.3, and as recommended (and almost forced) on the website for Windows I installed it from Microsoft Store. I had problems with the previous installed version and the path, but once solved, the system works.

It has however an annoying issue with the installed path, as can be seen in this error log:

`MethodError: no method matching Day(::Tuple{String, Int64})

Closest candidates are:
Day(!Matched::DateTime)
@ Dates C:\Users\user.julia\juliaup\julia-1.10.2+0.x64.w64.mingw32\share\julia\stdlib\v1.10\Dates\src\periods.jl:34
Day(!Matched::Date)
...`

As an be seen, the error liked C:/Users/user/.julia/juliaup/julia-1.10.2 instead of the real file C:\Users\user.julia\juliaup\julia-1.10.2+0.x64.w64.mingw32\share\julia\stdlib\v1.10\Dates\src\periods.jl:34 . I suspect that it is related with the name or version number of the binary containing a "+" sign breaks the link formation. Since it is the recommended installation for Windows, can this problem be fixed with a new release (and special characters avoided in the future)?

[davidanthoff]

I'm not following :) The "error liked"? Not sure what that means... The path in the stack trace looks correct to me?

Are you maybe talking about hyperlinks in a terminal? If so, what terminal are you using?

[vAdalid]

Yes, I guess that is the right word, thanks. I'm running the code in a Jupyter notebook.
I attach a capture so it is easier to see.

[davidanthoff]

What client are you using to open the Jupyter notebooks? I think at the end of the day this is a bug in that client, i.e. it is using an incorrect hyperlink detection algorithm.

[vAdalid]

Sure it is, but if Microsoft didn't fix Visual Studio for its own Onedrive professional paths, I doubt they'll ever fix it for anything else. Removing the "+0" from the version seems a trivial fix that will improve Julia usability on Visual Studio, and maybe other editors.

[davidanthoff]

MS has been really quite fantastic with addressing issues in VS Code that we reported, so lets see. Could you open an issue over at the microsoft/vscode repo with this and then link it?

Can you elaborate what you mean with the Onedrive story? Just not clear to me.

We can't easily remove the "+0", it does serve a purpose, it allows us to repackage versions if we make some kind of mistake at some point.

[vAdalid]

I checked before, and seems to have been reported multiple times, microsoft/vscode#92386 would be the most related microsoft/vscode#204908 the most recent.

About Onedrive, the name of the folder is "OneDrive - enterprise_name", so it breaks the hyperlink too (and there is no way to rename the folder)
"[c:\Users\user\OneDrive](file:///C:/Users/user/OneDrive) - enterprise_name\app_folder\TIME.jl:34"

Maybe the "+" can be replaced with another character like "_" or the repackage have some a, b c letter instead?

[vAdalid]

As update, I tried running directly in VS terminal (julia executed in powershell) and the hyperlink works even with the "+". May it be related to the Julia or Jupyter extensions?

I'm using Visual Studio Code 1.87.2 Julia 1.75.2 Jupyter v2024.2.0

[davidanthoff]

All the issues you link to report this problem in the VS Code terminal, and then MS fixed those problems and as you found out our links work correctly in the VS Code terminal.

The right thing to do here is to open an issue in the microsoft/vscode repository that reports that these links don't work in notebooks. The basic Jupyter notebook support lives in the microsoft/vscode repo, so I would report it there.

I'd like to keep the + ideally as that is the proper way to construct a semver version.

[vAdalid]

I'll check where to open the issue then, it is worth for them to fix it in any case.

As about the +, maybe there is no need to change the version name, just the name of the folder, with a general folder without version, or assume that it makes no sense to have two folders if one had to be repackaged by a mistake, so there is only one 1.10.2 version to be kept.

[StefanKarpinski]

It seems like this is a VS Code issue. There's nothing wrong with having a + in a file name on any platform. It's much nicer to have the file name match the actual version name and not have to do some awkward translation back and forth.