After creating a virtual environment All libraries have errors

I have several screen captures to show this error. This appears to be very similar to an issue reported by

Alberto.Gonzalez
“Validation errors after installation of SysIDE Automator”
Jul 2025

I am fairly certain this is a user configuration error, but several things seem unique. See the bottom of this post for the questions. But first, my environment:

Windows 10:
22H2 (Build 19045.7663)

Visual Studio Code:
Version: 1.135.0 (system setup)
Commit: 08d4889f9ec4a1685d257b9b95de036c8e1ce1e5
Date: 2026-08-25T14:26:52Z
Electron: 42.8.1
ElectronBuildId: 14906494
Chromium: 148.0.7778.280
Node.js: 24.18.1
V8: 14.8.178.38-electron.0
@github/copilot: 1.0.81-0
@github/copilot-sdk: 1.0.11
OS: Windows_NT x64 10.0.19045

I only have Syside Modeler installed; It is version 0.10.3.

After the virtual environment is created, I get the following errors.

It appears to me that the virtual environment was not created correctly and that the Syside Professional library is in conflict with it. I did find a fix by “noodling” around the Internet with Google AI. The recommendation was to create/edit a syside.toml file located on Windows 10 at:

%appdata%\syside

After creating that file with the contents:

include = ["**/*.sysml"]
exclude = [".venv", "lib", "out", "dist"]

[lint]
# This keeps the standard library checks active for your actual code
# while preventing the linter from digging into the .venv folder.

And then reloading my editor with Ctrl + Shift + P and run the command Developer: Reload Window which forces the Syside Editor to scan the new configuration. All seems to be okay now.

The questions are:

  1. If this toml file needs to be part of the runtime configuration for the virtual environment to behave correctly, where is it documented?

  2. Is this the correct configuration and fix for this situation? If not, what is the correct fix?

  3. I know what a .venv for Python does. Is there some version limitation for Syside that requires this?

  4. Which Python should I be running? Using the Python: select interpreter My choices are

  • As you can see, I’ve selected my system-installed Python. Which Python should I use (my idea is the .venv)?

Best regards,

Richard

Hi Richard,

Caveat: I’m not on Windows so I’m guessing at a few things.

First, unless you are using python and the syside package (Automator), there is no need to have a python environment at all. If you are just editing .sysml or .kerml files in a directory, it’s fine to just open that directory in vscode with Modeler enabled. Modeler manages its standard library behind the scenes.

Second, if you are authoring python scripts importing syside in the same directory, a .venv is the correct way to scope your work. However, I strongly recommend interacting with the .venv (including creating it) via the tool uv. uv will manage the virtual environment AND the python version for you.

uv init --bare
uv add syside
uv run script.py

from within the directory is enough to create the correct environment and run the script.

Lastly, Modeler should indeed not pick up the library files in .venv (or indeed any directory beginning with .). This may be a bug; I’ll investigate internally. In the meantime, the syside.toml file

exclude = ["**/.venv"]

should be enough to ignore the spurious copy. Note the ** so that the exclusion also excludes other, nested venvs. The other lines in your syside.toml are not needed.

Adam Layne, PhD

@Adam_Layne

Thank you for such a quick reply. To help your understanding, I was using Syside’s Option to create a Python virtual environment in the Syside editor, thus:

The .venv was created, and then the issues I described occurred. So using the tool alone caused the errors? I still believe it was my ignorant user error. Is there help on this selection? If not, it needs to be added. A description of what this does seems to depend on a user’s knowledge of .venv creation and use. As the ol’saying goes, “Making things idiot proof is hard, as there is always a better idiot.” :wink:

I’ll try the external uv commands and see what happens.

I’ll modify my syside.toml as you suggest.

I did find the documentation on syside.toml located at Configure Editor — Syside.

My first question, “If this toml file needs to be part of the runtime configuration for the virtual environment to behave correctly, where is it documented?” still stands. Quick adoption of a product depends on new users being able to quickly stand up a correct environment, or at least be able to descern what needs correction.

V/r,

Richard

If I understood you correctly, .venv was created after starting Syside. Then the issue you are seeing is caused by a bug that hidden files and directories were not automatically ignored in file events sent by the editor. Fixing that for the next release. In the meantime, you can just restart Syside with Syside [Modeler]: Restart language server command (Ctrl+Shift+P to open up commands).

Hi @Daumantas,

Yes, the .venv was created after starting Syside. Here is a sequence of operations:

  1. Start Syside
  2. Edit files
  3. Use the Syside Modeler button and select “Create Python virtual environment with Syside Automator”
  4. (Syside creates the .vevn with all attendant files and directories)
  5. At this point, all of the files in the .venv\Lib\site-packages_syside\* begin to have the “not be marked as standard” error, as shown in the original post.
  6. After supplying the %appdata%\syside\syside.toml file with the exclude = ["**/.venv"] and then reloading the window (or restarting the language server) cleared the errors.

I hope this clarifies the sequence of actions that will aid in the correction in the next release. This root repair (root cause?) was the statement ofexclude = ["**/.venv"] in the syside.toml file. The file has to be there to keep the errors from occurring.

V/r,
Richard.

Richard,

In a fresh recreation of your steps above, do the errors only show in the library files after you navigate to them in the editor, or do they show immediately after creating the venv, while you’re still simply looking at the pre-existing file you were editing?

If they only show once you navigate to one of the venv files, do all the library files show errors after navigating to one of them, or does only the one you navigated to show errors?

I have not yet been able to reproduce the behavior you’re experiencing, so these answers will be helpful.

Adam

I’ll tear down my installation and start fresh and see if it behaves the same. It will be later today (I am GMT-5).

It shouldn’t be necessary to tear down your installation entirely. Simply starting from your step 1. in a fresh, empty directory will give me the information I need for now.

Hi @adam_layne ,

I created a clean workspace as requested.

Note:

The %appdata%\syside\syside.toml file has been removed and is no longer influencing the environment. I’ve added some files as shown by copying them into the folder:

I then open the DroneModel.sysml file

Invoke the Syside Modeler to create a Python VE w/Syside Automator

And voilà! The .venv gets created, and the errors occur as shown:

And then, I perform a restart the modeler server, thus:

image

Then all the .venv "…package should not be marked as standard " errors go away.

It sure sounds like an initialization issue.

V/r,
Richard

Many thanks, Richard. This will help us identify the fix!