logic for getManimPath is wrong

[NutchapolSal]

in src/sideview.ts, the code to get path to venv folder actually obtains path to the python executable, so getManimPath creates paths like D:\manim\venv\Scripts\python.exe\Scripts\manim

also, when the manim-sideview.defaultManimPath config value is an absolute path, the code doesn't check for this resulting in paths like D:\manim\venv\Scripts\python.exe\Scripts\D:\manim\venv\Scripts\manim.exe. running the manim executable directly without activating the venv first seems to run fine, so it shouldn't need to activate venvs and mess with paths if an absolute path is specified.

OS: Windows 11
Extension version: v0.2.14

[Rickaym]

Is it not that env.folderUri.fsPath returns the path to the folder, i.e., D:\manim\venv\ in which case the \Scripts\manim.exe gets appended correctly? That has been the case from my tests. It would be helpful if you show some of the logs from manim sideview.

And I do think you're right on the absolute path part. I'll be patching that today.

[NutchapolSal]

2024-11-02 18-50 manim sideview log.txt
(if you're confused about why there's D: and G:, yes i have my venv and my .pys in separate locations. turns out accessing a venv on a NAS is slow)

Is it not that env.folderUri.fsPath returns the path to the folder

that should be the case according to the types, but my vscode gives out the path to exe for some reason
actually, if you could reliably get the exe path, you wouldn't need to mess with the Scripts or bin thing. just use the parent of the exe.

[Rickaym]

actually, if you could reliably get the exe path, you wouldn't need to mess with the Scripts or bin thing. just use the parent of the exe.

I suppose I can add a check to see if it is returning an exe path. But very peculiar.