We expect that at least some users will want to work on multiple projects simultaneously. For example, the SysML standard library is composed of multiple projects, all of which are expected to have the same metadata matching a specific version of the specification. In package managers like Cargo, working on multiple projects is supported via the concept of a workspace. To avoid reinventing the wheel, we probably should just try to adapt an existing concept instead.

Requirements (the list is non-exhaustive and should be updated once we learn new things):

• All dependencies are considered together. This means:

  • A single lock file for all projects.
  • A single environment folder with dependencies for all projects.

• Commands should recognize that they are in a workspace and change their behavior accordingly.

Here is my proposal how each command should work when executed in the context of a workspace:

• sysand init and sysand new: should have a flag for automatically adding the created project to the workspace. If the flag is not submitted, they should report a warning that the workspace is detected and the user should manually update it.
• sysand add, sysand remove, sysand include, sysand exclude, sysand info, sysand print-root: when executed from a project's folder, should act normally. When executed from the workspace's folder, should show an error asking to use flag --project <project name or one of its IRIs> to specify in which project's context the command should be executed.
• sysand build: build kpars for all projects in the workspace and put them into the workspace output folder named <project-name>-<project-version>.kpar.
• sysand lock: should consider all projects in the workspace together and generate a single lock file.
• sysand env: should have a single environment for the workspace.
• sysand env sources: by default lists sources of all projects, but should have a flag for list of a single project.
• sysand sync: use the workspace's lock file and environment.
• sysand sources: list source files for all projects, unless a specific project is specified via flag.

I propose to identify the workspace by having .workspace.json file that lists the projects that belong to it. For example:

{
    "projects": [
        {
            "path": "projectGroup1/project1",
            "iris": [
                "urn:kpar:project1"
            ]
        },
        {
            "path": "projectGroup1/project2",
            "iris": [
                "urn:kpar:project2"
            ]
        },
        {
            "path": "project3",
            "iris": [
                "urn:kpar:project3"
            ]
        }
    ]
}