jacking in broken in 2.0.127

[Bellarmine-Head]

I launched VS Code against a Lein project this evening (on Windows 10, with WSL 2 accessing an Ubuntu 18.04 install of Clojure etc.).

Immediate problem... jacking in doesn't work... at all.

Downgraded the Calva extension to 2.0.126 and jacking in works again.

[shaohong]

Similar situation here. I use Mac Catalina and nothing happens when I pressed jack-in shortcut or invoke it from command palette. I downgraded to 2.0.125 and it is working.

[birdspider]

same here with deps.edn based project

[kstehn]

this is still broken for multi-project structure
i have live-share installed but also when i disable it it doesn't work

it seems to be that the project-root isn't found

[bpringe]

@kstehn Can you describe the project set up so I can repro? I don't normally work in multi-project setups, and could guess, but just want to make sure I'm working on the right fix if I get to it soon. Maybe @svdo would have some time to look at this too?

[kstehn]

Of course.
I have a folder called repos and in there some clojure projects.
So my structure is like

repos
    project A
       project.clj
    project B
       project.clj

So and i have opened this with vsCode and also saved it as a workspace so i can define some settings like envs and so on.
Then i tried to jack-in so i opened a file from project a and used jack-in.
But it said that there is no supported project file found which i assume is like project.clj/deps.edn and so on.

[svdo]

Thanks for fixing this @bpringe! I was planning to look at it but I didn't have time yet.

[AHAHAC]

This still doesn't work in 129

[kstehn]

can confirm this too 😅
this time i get
Unable to resolve filesystem provider with relative file path 'd:\<repo-path>/.calva/output-window/.clj-kondo'
The project-root () is correct now also in regards to windows.
But this seems weird regarding that the path gets created by vscode.Uri.

[svdo]

Just to clarify:

• Is this a Windows-only issue or does anyone still experience this with version 2.0.129 on macOS / Linux?
• Is this related to multi-project workspaces (i.e. using a .code-workspace file) or is this also broken for "normal" projects?

[kstehn]

Normal and workspaces have this problem
my guess would be windows alone but not sure

[svdo]

Right. I don't have a Windows machine that I can use to reproduce this :(

[kstehn]

that is okay :)
my guess after doing some quick debugging
that vscode.Uri.join(<ProjectRoot>, ".calva", "window") returns a wrong result
normally it should create a correct Uri depending which plattform is getting used

[bpringe]

@svdo No problem!

I'll look into fixing this for Windows and try to get testing on all platforms before another release! I didn't want to change the use of the vscode.Uri because I think @svdo added this as a necessity for live share. I'm guessing this has been an issue on windows since .127, though... I wonder if I can reasonably test this on linux with Windows in a VM...

[bpringe]

@kstehn @svdo Do either of you have access to Windows, and if so, can you debug this there? I've looked around the code but it's very hard for me to fix it blindly. This needs to be fixed on Windows, and then we can test the vsix on Mac/Linux. @PEZ

[bpringe]

Some info to point anyone who can look into this in the right direction:

I think the error is happening here:

calva/src/nrepl/jack-in.ts

Line 159 in 2cfb94c

await outputWindow.initResultsDoc();

But it's likely happening as a result of state set here:

calva/src/nrepl/jack-in.ts

Line 143 in 2cfb94c

await state.initProjectDir();

[kstehn]

I started the debugging
But as i said the error is the result of Uri.join the path of the Root_Dir is correct 🤔

But i can take a look Tomorrow regarding those two lines

[bpringe]

Yeah, that line you pointed out looks fine by itself though. There's no real other way to call it (I could be wrong here), if we're talking about this line:

calva/src/results-output/results-doc.ts

Line 36 in 2cfb94c

return vscode.Uri.joinPath(projectRoot, ".calva", "output-window");

So I was guessing the issue could be something with the projectRoot uri (even if it looks correct at first glance), which is set in initProjectDir. But like I said, I can only really guess since I'm not using Windows. 😄

[kstehn]

Yes That Was also my thought
So i looked what projectRoot is at this point and it Shows d:\repos\project-dir so in regards to Windows paths it is correct and also points to the correct folder

[bpringe]

I see. I was just thinking, specifically, since it's a URI object, something else could have been wrong with it even if the path looked correct, but probably not.

[bpringe]

This should be fixed in 2.0.130 🤞