feat: add environment metadata file sysand_env/env.toml

[victor-linroth-sensmetry]

This PR adds a env.toml containing metadata for the projects installed in the local environment
(inluding editable projects not present inside the sysand_env folder).

Each project has the following fields:

• publisher: String (optional).
  Publisher of the project. Intended for display purposes.
• name: String (optional).
  Name of the project. Intended for display purposes.
• version: String (required).
  Version of the project.
• path: String (required).
  Path to the root directory of the project.
  If the project is not editable this should be relative
  to the env directory and otherwise it should be relative
  to the workspace root.
• identifiers: Array of strings (required for non-editable projects)
  List of identifiers (IRIs) used for the project.
  The first identifier is to. be considered the canonical
  identifier, and if the project is not editable this
  is the IRI it is installed as. The rest are considered
  as aliases. Can only be empty for editable projects.
• usages: Array of strings.
  Usages of the project. Intended for tools needing to
  track the interdependence of project in the environment.
• editable: bool.
  Indicator of wether the project is fully installed in
  the environment or located elsewhere.
• workspace: Indicator of wether the project is part of a workspace.

The current implementation doesn't change how projects.txt works and is intended to offer a transition step between env structures. The env.toml isn't directly managed by
LocalDirectoryEnvironment since such a thing will likely require a change in the
WriteEnvironment trait. In particular it would have to offer the ability to give alias identifiers in addition to the main IRI used for installation (since we want to communicate the dependency structure between projects we need all aliases as well, at least if we want to incrementally add or remove from the environment).

Also since the current implementation of workspaces only affects the build command, the workspace field isn't really effective at the moment, but should work as expected once the workspace feature catches up.

Example:

# This file is automatically generated by Sysand and is not intended to be edited manually.

version = "0.1"

[[project]]
name = "SYSMOD"
identifiers = [
    "urn:kpar:sysmod",
]
version = "5.0.0-alpha.2"
path = "a0aacee34dd4cd5e2d07ab43d5e30772ec86dbf3c8fafb033bad338dd7a0f02e/5.0.0-alpha.2.kpar"
usages = [
    "urn:kpar:analysis-library",
    "urn:kpar:cause-and-effect-library",
    "urn:kpar:data-type-library",
    "urn:kpar:function-library",
    "urn:kpar:geometry-library",
    "urn:kpar:metadata-library",
    "urn:kpar:quantities-and-units-library",
    "urn:kpar:requirement-derivation-library",
    "urn:kpar:semantic-library",
    "urn:kpar:systems-library",
]

[[project]]
name = "Testing"
version = "0.0.1"
path = "."
usages = [
    "urn:kpar:sysmod",
]
editable = true
files = [
    "test.sysml",
    "test.kerml",
]

[andrius-puksta-sensmetry]

Information provided (if available) includes

• Publisher
• Name
• Directory/Files
• Usages

What about IRIs for non-PURL usages? Since names will likely not be unique (e.g. 10 projects named "Requirements"), how will they be disambiguated to the user?

[victor-linroth-sensmetry]

What about IRIs for non-PURL usages? Since names will likely not be unique (e.g. 10 projects named "Requirements"), how will they be disambiguated to the user?

Well, our solution for name collisions is to use namespaces(/publishers). If you don't use them, then you don't get the solution.

[daumantas-kavolis-sensmetry]

This is communicated through a "resolved manifest" current.toml

current.toml is very non-descriptive or sounds quite irrelevant to an environment. env.toml or projects.toml would be far clearer.

In particular this means paths are absolute

I highly suggest using paths relative to manifest/sysand_env for paths inside sysand_env and project folders as majority of the paths will have an identical prefix that can trivially be removed.

What about IRIs for non-PURL usages? Since names will likely not be unique (e.g. 10 projects named "Requirements"), how will they be disambiguated to the user?

Why would anyone care about collisions in what is effectively a display name? If a user has multiple projects named the same, they have bigger issues than some ambiguous name.

[daumantas-kavolis-sensmetry]

Maybe also add workspace = [0, 1, ...] top-level property that controls workspace/project roots for analysis?

[andrius-puksta-sensmetry]

files: Array of strings (only for editable projects).
In case of an editable project these are the files
belonging to the project. Intended for tools that
are not able to natively parse and understand the
projects .meta.json file. Paths should be relative
to the path of the project.

Since editable projects are expected to change frequently, how will
new/removed files be handled?

workspace: Indicator of wether the project is part of a workspace.

Which workspace? Workspace that owns this env? Or another unrelated one?

[victor-linroth-sensmetry]

Since editable projects are expected to change frequently, how will new/removed files be handled?

Hmm, good question. Could maybe be updated whenever the env is updated. Or simply simply drop files and say tools will need to parse the .meta.json if they want exact files. I've been leaning towards that before.

Which workspace? Workspace that owns this env? Or another unrelated one?

Yeah, I think the idea at least is to have common lockfile, env and build directory in a workspace. This is to indicate of that is the case and which projects are workspace memebers.

[andrius-puksta-sensmetry]

Since editable projects are expected to change frequently, how will new/removed files be handled?

Hmm, good question. Could maybe be updated whenever the env is updated. Or simply simply drop files and say tools will need to parse the .meta.json if they want exact files. I've been leaning towards that before.

Agree on dropping files. It's not env responsibility to precisely keep track of projects outside of it.

Which workspace? Workspace that owns this env? Or another unrelated one?

Yeah, I think the idea at least is to have common lockfile, env and build directory in a workspace. This is to indicate of that is the case and which projects are workspace memebers.

Ok, so current workspace. Yeah, having common env/lockfile/build dir is a sensible thing to do.

[andrius-puksta-sensmetry]

The env.toml isn't directly managed by
LocalDirectoryEnvironment since such a thing will likely require a change in the
WriteEnvironment trait. In particular it would have to offer the ability to give alias identifiers in addition to the main IRI used for installation (since we want to communicate the dependency structure between projects we need all aliases as well, at least if we want to incrementally add or remove from the environment).

Add a TODO to this effect somewhere. Not sure what to do about this longer term, as env.toml also includes editable projects, which are not installed into the environment per se, and also the current project(s)... WriteEnvironment then would have to be somehow coupled with current workspace/projects, not sure how to go about that.

[victor-linroth-sensmetry]

Add a TODO to this effect somewhere. Not sure what to do about this longer term, as env.toml also includes editable projects, which are not installed into the environment per se, and also the current project(s)... WriteEnvironment then would have to be somehow coupled with current workspace/projects, not sure how to go about that.

Put a TODO in command_sync as that's the main point of generating env.toml.

[andrius-puksta-sensmetry]

Looks good.