Background

SysML v2 will have (at least) two kinds of packages that will be distributed through KPAR files and package managers.

The first kind is all about reusable assets that are not meant to be edited by the end-user. Think of ontologies, frameworks, baselines. Let's call these libraries in this issue. The current Sysand design works well for libraries – the libraries and their contents are hidden from direct view of the end-user in the sysand_env folder and SysML v2 authoring tools can be instructed not to allow any changes to models living in these folders. For example, in the current sysand.org package index, libraries would be the SYSMOD, PLEML, CDF Reference Data Library.

The second kind of packages is about example models, or training materials, or tools for which SysML v2 is the input/output interface and the users are expected to interact directly with the files of the package. Let's call these packages models in this issue. These models should not be hidden from the user's view after installation, and SysML v2 authoring tools should allow the users to edit them freely. For example, in the current sysand.org package index, models would be the SysML v2 Flashlight Starter Model, and Comet Interceptor.

At the moment, there is no way to easily install these models through Sysand in an easy-to-explore manner. The only way is to go to sysand.org and manually unzip the KPAR files.

Proposed solution

Implement "editable" mode into Sysand CLI that downloads the requested KPAR and all its dependencies. While the dependencies are installed into the sysand_env folder as usual, the requested KPAR itself is extracted into the root of the project so the user can easily explore and interact with it.

The CLI could either be a new command sysand edit <IRI> or a sysand add <IRI> --editable. Other suggestions welcome.

Open questions

• What happens with .project.json and .meta.json? Do we overwrite them with the requested KPAR's .project.json and .meta.json? Or do we add the requested package as a normal usage into .project.json (but maybe with a non-standard additional editable: True field?
  • Going the git clone-like way ensures that these JSONs do not clash, as they do not exist yet before running sysand edit or whatever the final command will be.