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 <iri> (sysand.add doesn’t seem to do exactly the same…)
sysand env list
sysand remove <iri>
sysand env uninstall <iri>
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 <iri> 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!
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.
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, 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.
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.
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.
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
looking forward to future developments!