Cannot add WSL TeXLive/MikTeX as an SDK

[ZnqbuZ]

Type of JetBrains IDE (IntelliJ, PyCharm, etc.) and version

IntelliJ IDEA 2021.3.3

Operating System

Host: Windows 11
WSL: Kali Linux, Ubuntu

TeXiFy IDEA version

0.7.15

What I did (steps to reproduce)

The plugin cannot recognize TeXLive or MikTeX distribution I installed in WSL, neither manually nor through package manager. (but can still compile .tex files)

When I try to add an SDK, e.g. TeX Live SDK, error messages are like:
Invalid TeX Live SDK home directory: Cannot run program "\wsl$\kali-linux\usr\local\texlive\2021\bin\x86_64-linux\pdflatex": CreateProcess error=3, Cannot find the specific path

Minimal example to reproduce the problem

\documentclass{article}
\begin{document}
    
\end{document}

(if applicable) The full stacktrace of the exception thrown (When I click "Setup SDK")

2022-03-27 05:46:20,048 [  24988]   WARN - s.ui.configuration.SdkDetector - Failed to process detected SDK for MiKTeX Windows SDK at ???: ??????????????????. Illegal char <:> at index 3: ???: ??????????????????
java.nio.file.InvalidPathException: Illegal char <:> at index 3: ???: ??????????????????
        at java.base/sun.nio.fs.WindowsPathParser.normalize(WindowsPathParser.java:182)
        at java.base/sun.nio.fs.WindowsPathParser.parse(WindowsPathParser.java:153)
        at java.base/sun.nio.fs.WindowsPathParser.parse(WindowsPathParser.java:77)
        at java.base/sun.nio.fs.WindowsPath.parse(WindowsPath.java:92)
        at java.base/sun.nio.fs.WindowsFileSystem.getPath(WindowsFileSystem.java:229)
        at java.base/java.nio.file.Path.of(Path.java:147)
        at java.base/java.nio.file.Paths.get(Paths.java:69)
        at com.intellij.openapi.roots.ui.configuration.SdkDetector.detect(SdkDetector.java:157)
        at com.intellij.openapi.roots.ui.configuration.SdkDetector$2.run(SdkDetector.java:208)
        at com.intellij.openapi.progress.impl.CoreProgressManager.startTask(CoreProgressManager.java:436)
        at com.intellij.openapi.progress.impl.ProgressManagerImpl.startTask(ProgressManagerImpl.java:120)
        at com.intellij.openapi.progress.impl.CoreProgressManager.lambda$runProcessWithProgressAsync$5(CoreProgressManager.java:496)
        at com.intellij.openapi.progress.impl.ProgressRunner.lambda$submit$3(ProgressRunner.java:244)
        at com.intellij.openapi.progress.impl.CoreProgressManager.lambda$runProcess$2(CoreProgressManager.java:188)
        at com.intellij.openapi.progress.impl.CoreProgressManager.lambda$executeProcessUnderProgress$12(CoreProgressManager.java:624)
        at com.intellij.openapi.progress.impl.CoreProgressManager.registerIndicatorAndRun(CoreProgressManager.java:698)
        at com.intellij.openapi.progress.impl.CoreProgressManager.computeUnderProgress(CoreProgressManager.java:646)
        at com.intellij.openapi.progress.impl.CoreProgressManager.executeProcessUnderProgress(CoreProgressManager.java:623)
        at com.intellij.openapi.progress.impl.ProgressManagerImpl.executeProcessUnderProgress(ProgressManagerImpl.java:66)
        at com.intellij.openapi.progress.impl.CoreProgressManager.runProcess(CoreProgressManager.java:175)
        at com.intellij.openapi.progress.impl.ProgressRunner.lambda$submit$4(ProgressRunner.java:244)
        at java.base/java.util.concurrent.CompletableFuture$AsyncSupply.run(CompletableFuture.java:1700)
        at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
        at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
        at java.base/java.util.concurrent.Executors$PrivilegedThreadFactory$1$1.run(Executors.java:668)
        at java.base/java.util.concurrent.Executors$PrivilegedThreadFactory$1$1.run(Executors.java:665)
        at java.base/java.security.AccessController.doPrivileged(Native Method)
        at java.base/java.util.concurrent.Executors$PrivilegedThreadFactory$1.run(Executors.java:665)
        at java.base/java.lang.Thread.run(Thread.java:829)

[ZnqbuZ]

I've skimmed through the code, and it seems that the plugin does not support Latex SDK in WSL. I will try to add this support and perhaps make a pull request several weeks later, if it goes well.

[PHPirates]

You might be right, I think the normal TeX Live SDK should support it, but if it has trouble running pdflatex then something may need to be fixed.
You can check usages of LatexDistributionType.WSL_TEXLIVE to see how WSL support is mixed in, it's basically just hardcoded fixing of paths on the fly. Would be great if you could help!
I don't think we need a separate WSL SDK type, it's still TeX Live but you just access it differently.

We should update https://github.com/Hannah-Sten/TeXiFy-IDEA/wiki/WSL-support

[ZnqbuZ]

You might be right, I think the normal TeX Live SDK should support it, but if it has trouble running pdflatex then something may need to be fixed. You can check usages of LatexDistributionType.WSL_TEXLIVE to see how WSL support is mixed in, it's basically just hardcoded fixing of paths on the fly. Would be great if you could help! I don't think we need a separate WSL SDK type, it's still TeX Live but you just access it differently.

We should update https://github.com/Hannah-Sten/TeXiFy-IDEA/wiki/WSL-support

I'm not sure if I missed anything, but LatexDistributionType.WSL_TEXLIVE is only used in compiler (and indeed the plugin can compile tex files even though there is no project sdk set), so I think the problem is that functions in LatexSdkUtil are not compatible with WSL, since runCommandWithExitCode() does not fix paths.

For example,

// nl.hannahsten.texifyidea.settings.sdk.LatexSdkUtil
val isPdflatexInPath: Boolean by lazy {
    "pdflatex --version".runCommand()?.contains("pdfTeX") == true
}

this function does not work for WSL. (but works under both Win and Linux, since .exe can be omitted in Win)

I think I'll need to rewrite the code about sdk to fix this. Maybe let all sdks extends a class similar to LatexSdkUtil instead and let WSL override some functions to fix paths. (However, the plugin then can only compile files when a proper project sdk is set)

[PHPirates]

I think the problem is that functions in LatexSdkUtil are not compatible with WSL
Yes, I think so too, and also all of the inspections and other things that run latex commands are probably using the wrong paths.

The question is, is it the responsibility of the caller or of the runCommand functions to fix the paths for WSL? It could be the most practical to check in runCommand if no explicit full path to an executable is given, and if not, check if the project sdk is a WSL thing and if so fix paths. But not sure, many solutions are possible :)

[ZnqbuZ]

It could be the most practical to check in runCommand if no explicit full path to an executable is given, and if not, check if the project sdk is a WSL thing and if so fix paths.

Indeed, I thought the same thing, so the problem is LatexSdkUtil:

1. Since LatexSdkUtil is designed to be not specific to sdk, some funs, such as getDistribution, does not know whether the sdk is in wsl, so it cannot fix path;
2. while some other funs, such as getExecutableName, use project as a param, which is kinda against the "not specific" designation.
3. I don't understand why there are so many get funs in LatexSdkUtil. Acutally, funs like getExecutableName should be, I think, methods of sdk object, instead of static funs. Is there any specific reason or advantage?

In my opinion, it's better to move most funs in LatexSdkUtil to nl.hannahsten.texifyidea.settings.sdk.LatexSdk, so each sdk can determine those methods' behaviours depending on whether it is in win, linux, mac, or wsl. Besides, in this way, I think it would be more convenient to manage different versions of the same type sdk (TeXLive 2020,2021...)

After such change, I would replace most calls to LatexSdkUtil by calls to project sdk's methods.

Would you agree to this plan?

[PHPirates]

No, that util I think evolved from a predecessor of the SDK functionality, and I only partially moved functionality into the SDK classes so I would appreciate if you clean it up :)
Yes, that sounds more sensible. Just make sure that it all still works when there is no SDK present, e.g. when someone has a completely different language SDK selected as project SDK, or when the notion 'SDK' is simply not present at all, like in PyCharm.

[ZnqbuZ]

Just make sure that it all still works when there is no SDK present

I see. Then, in this case I would create sort of a "NoSdk"(or "UnknownSdk") as the project sdk, so it would still work fine with this "sdk" as long as pdflatex (or other latex compiler) exists. Or, it's also all right to use TexliveSdk, since the fun isValidSdkHome is just checking if pdflatex exists.

Anyway, I would try to make it work for such no-sdk case.

[PHPirates]

@ZnqbuZ Still interested? Otherwise I'll fix it.

[ZnqbuZ]

@ZnqbuZ Still interested? Otherwise I'll fix it.

Yes, I'm still working on it. Debugging on multi platforms takes a lot of time...

[PHPirates]

Great! No problem, please ask me if you need help. I have both Windows with WSL and native Arch Linux available.

[PHPirates]

Please consider changes in #2381 to avoid conflicts