Thank you for sharing your code snippet and traceback – both are very helpful.
It appears you are triggering the latter – your traceback indicates that a call was made to
_repr_svg_() which is reasonably explained by your line of code,
knime.Workflow(workflow_path = workflow, workspace_path = workspace), being rendered for the screen. If you modify this line of your code snippet to instead store the
Workflow in a variable, the attempt to render it with an SVG will be eliminated and the
FileNotFoundError will no longer occur. That is, change that line of code to read:
wf = knime.Workflow(workflow_path=workflow, workspace_path=workspace)
The question remains: why did it not find the SVG file in that location? You mention moving the workflow on disk to a new location and now you find an SVG file is indeed appearing in the workflow’s new directory. I also notice that your Python code references locations that begin
"/mnt/C/..." which suggests that you might be using Windows Subsystem for Linux (WSL) or possibly Cygwin on your Windows system at least when running your Python scripts. I wonder if there is any difficulty with resolving paths correctly on your system when bouncing between using WSL and the native OS – that is not WSL’s fault, per se, but is something that must be thoughtfully guarded against when using native programs and WSL-dependent programs together. As a diagnostic tool, you might try modifying this example code to verify that you indeed have the full paths to things exactly right for your system, starting with the path to the executable and then verify the paths to your workflows:
>>> import pathlib
>>> exec_location = r"/mnt/C/Program Files/KNIME/knime.exe"
>>> exec_location2 = r"C:\Program Files\KNIME\knime.exe"
Keep in mind that the full path to the workflow may be provided as a single argument to the
knime.Workflow class during instantiation. Separating into two arguments, workflow and workspace paths, is supported and fine but can sometimes cause unnecessary confusion.
I hope this helps,