Dependencies

Sometimes you may wish to use a project that isn’t resolvable through an available index or you want to override the dependency resolution for other reasons. Or you may just want to replace a URL usage with a URN usage for better readability. In any case you can do this by adding the appropriate IRI and sources to a project entry in the sysand.toml configuration file at the root of your project. This follows the same structure as found in the lockfile, where identifiers are given as a list of IRIs and sources are a list of sources. A project may have multiple identifiers in case it is referred to differently by different projects, and multiple sources where the additional ones after the first serve as backups in case the previous ones fail to resolve. Note that these should be sources of the exact same project as determined by its checksum, as otherwise you are likely to run into problems when syncing against a lockfile.

Below we describe how to add overriding sources directly to the configuration file, but it is also possible to do through the command line interface with the sysand add command by using one of the --from-* flags to have Sysand try to guess a project source from the path/URL, or using one of the --as-* flags if you want to specify exactly which type of project source you want.

All paths in project sources are assumed to be relative to the root of your project.

Local projects

To specify the source of a project that you have locally in a directory ./path/to/project by the identifier urn:kpar:my-project, is done by adding the following entry to your sysand.toml.

[[project]]
identifiers = [
    "urn:kpar:my-project",
]
sources = [
    { src_path = "path/to/project" },
]

This source corresponds to the --as-local-src flag.

Local editable projects

Normally when you add a project as a usage, Sysand will copy and install it, so any changes made to the original project afterwards will not affect the installed project. For local projects you also have the option to add them as “editable” usages, meaning the project won’t be copied and will instead just be referred to where it is originally located. A local project is specified as editable in sysand.toml by adding

[[project]]
identifiers = [
    "urn:kpar:my-project",
]
sources = [
    { editable = "path/to/project" },
]

This source corresponds to the --as-editable flag.

Local KPARs

If you have a project locally available as a compressed KPAR this can be identified by urn:kpar:my-kpar-project by adding

[[project]]
identifiers = [
    "urn:kpar:my-kpar-project",
]
sources = [
    { kpar_path = "path/to/project.kpar" },
]

to your sysand.toml. This source corresponds to the --as-local-kpar flag.

Remote projects

Remote project are those available through URLs, and similar to local projects the way to specify them as sources depends on which format they come in.

To specify a KPAR available at a URL as a source, add

[[project]]
identifiers = [
    "urn:kpar:remote-kpar-project",
]
sources = [
    { remote_kpar = "https://www.example.com/path/to/project.kpar" },
]

to your sysand.toml. This source corresponds to the --as-remote-kpar flag.

For projects that are not packaged you can either use

[[project]]
identifiers = [
    "urn:kpar:remote-project",
]
sources = [
    { remote_src = "https://www.example.com/path/to/project" },
]

or, if the project is hosted on a Git forge like GitHub, GitLab etc. use

[[project]]
identifiers = [
    "urn:kpar:remote-git-project",
]
sources = [
    { remote_git = "https://github.com/my_user/project.git" },
]

These sources corresponds to the --as-remote-src and --as-remote-git flags respectively.

Note

Currently there is no way to specify a particular git reference like e.g. a branch, tag or commit. It is also currently not possible to specify a project path in a repository.