# Python language bindings **URL:** \ **Category:** Feature Requests\ **Created:** [June 8, 2026, 3:08pm UTC](https://forum.sensmetry.com/t/python-language-bindings/493 "2026-06-08T15:08:02Z")\ **Posts on this page:** 5\ **Page:** 1
**Author:** ![jbussemaker](https://avatars.discourse-cdn.com/v4/letter/j/9de0a6/32.png) [@jbussemaker](https://forum.sensmetry.com/u/jbussemaker)\ **Post date:** [June 8, 2026, 3:08pm UTC](https://forum.sensmetry.com/t/python-language-bindings/493/1 "2026-06-08T15:08:02Z")
Hello everyone, I’m currently implementing some functionality to semi-automatically manage dependencies using Sysand, and although I can get it to work there are some improvements to be made. I could not find Python bindings equivalent to the following commands: - `sysand add ` (`sysand.add` doesn’t seem to do exactly the same…) - `sysand env list` - `sysand remove ` - `sysand env uninstall ` - `sysand lock` Actually, the last 3 commands (remove, env uninstall, lock) I need when I want to “upgrade” a dependency (e.g. from v1.0.0 to v2.0.0). Why are all these commands needed? Why isn’t `sysand remove ` enough (analogously to `sysand add`, which also does a sync and a lock)? Also, there is no documentation of the Sysand Python language bindings. So I had to discover all the existing functions by trial and error. Do you plan to support Python language bindings (or also other languages) to the Sysand client as the same priority as the CLI? That said, everything else is working as expected, and I’m really happy with the new Sysand index! Greetings, Jasper ---
**Author:** ![Andrius\_Puksta](https://yyz2.discourse-cdn.com/flex008/user_avatar/forum.sensmetry.com/andrius_puksta/32/187_2.png) [@Andrius\_Puksta](https://forum.sensmetry.com/u/Andrius_Puksta)\ **Post date:** [June 11, 2026, 8:08am UTC](https://forum.sensmetry.com/t/python-language-bindings/493/2 "2026-06-11T08:08:42Z")
Hi Jasper, > [@jbussemaker](#): > > Actually, the last 3 commands (remove, env uninstall, lock) I need when I want to “upgrade” a dependency (e.g. from v1.0.0 to v2.0.0). Why are all these commands needed? Why isn’t `sysand remove ` enough (analogously to `sysand add`, which also does a sync and a lock)? We plan to have an upgrade (or similar) command, which would generally be the same as `remove old + add new + lock + sync`. Sysand environment (`.sysand`) is basically a cache, and we currently don’t do automatic cache cleanups. Extra projects there have no impact on sysand, they just take up space. We plan to make the caches global for a single user, and then it will be impossible to know if any of the cached projects is needed by a project somewhere. For this reason sysand currently never removes anything from the environment unless specifically requested with `env uninstall`. > [@jbussemaker](#): > > Also, there is no documentation of the Sysand Python language bindings. So I had to discover all the existing functions by trial and error. Do you plan to support Python language bindings (or also other languages) to the Sysand client as the same priority as the CLI? Bindings up to now were not a priority, so they currently contain only a small subset of CLI functionality. We are open to improving them if users request (like you did now, thanks!). Python bindings functionality and docs will be improved very soon, and we do plan to keep them up to date with CLI. Java bindings are currently mostly geared towards use by [SysML v2 Pilot](https://github.com/Systems-Modeling/SysML-v2-Pilot-Implementation), so their functionality will be limited for now. JS/WASM bindings currently are a prototype and we don’t have specific plans for them at the moment. Andrius ---
**Author:** ![jbussemaker](https://avatars.discourse-cdn.com/v4/letter/j/9de0a6/32.png) [@jbussemaker](https://forum.sensmetry.com/u/jbussemaker)\ **Post date:** [June 11, 2026, 9:38am UTC](https://forum.sensmetry.com/t/python-language-bindings/493/3 "2026-06-11T09:38:47Z")
Hi Andrius, Thanks for your answers 🙂 looking forward to future developments! Regarding `.sysand` being a cache: if that is the case then this should be made very clear and closely aligned with SysML tools like your own Syside suite. Because if I now open a project in VSCode, it will parse all `*.sysml` files in the project, including old/removed packages, and it will start complaining about duplicate package names and all kinds of other problems… Also, SysML file discovery using `syside.collect_files_recursively` would be broken. Also, a folder like `node_modules` is not a cache: it contains the actually-installed node packages as synchronized from the npm project lock file. Of course you can implement a caching mechanism to reduce the number of downloads, however the important part is I think which files will be actually made available to the user’s specific Sysand project using `sysand sync`. Greetings, Jasper ---
**Author:** ![TiloWiklund](https://yyz2.discourse-cdn.com/flex008/user_avatar/forum.sensmetry.com/tilowiklund/32/17_2.png) [@TiloWiklund](https://forum.sensmetry.com/u/TiloWiklund)\ **Post date:** [June 12, 2026, 2:20pm UTC](https://forum.sensmetry.com/t/python-language-bindings/493/4 "2026-06-12T14:20:04Z")
Cleanup of local environments is sometimes a bit tricky, especially in the presence of the ability to manually install things into them (like `sysand env install`), and different tools handle this slightly differently (compare for example plain `pip` with `uv`). We are working on improving/making this as intuitive as possible. For the moment, the actual “truth” about the list of files used by your project (as opposed to simply the files present in `.sysand`) is given by the `sysand sources` command, which lists all _relevant_ source files. We’re working on integrating this correctly into Syside. ---
**Author:** ![jbussemaker](https://avatars.discourse-cdn.com/v4/letter/j/9de0a6/32.png) [@jbussemaker](https://forum.sensmetry.com/u/jbussemaker)\ **Post date:** [June 12, 2026, 2:47pm UTC](https://forum.sensmetry.com/t/python-language-bindings/493/5 "2026-06-12T14:47:02Z")
Ah I missed that about the `sysand sources` command, that indeed fixes the issue of having multiple copies of libraries in the `.sysand` folder. But yeah, looking forward to future developments 🙂