cargo.json

title: Build

description:
The `build` field specifies a file in the package root which is a [build script](https://doc.rust-lang.org/cargo/reference/build-scripts.html) for building native code. More information can be found in the [build script guide](https://doc.rust-lang.org/cargo/reference/build-scripts.html).

```toml
[package]
# ...
build = "build.rs"
```

The default is `"build.rs"`, which loads the script from a file named
`build.rs` in the root of the package. Use `build = "custom_build_name.rs"` to
specify a path to a different file or `build = false` to disable automatic
detection of the build script.

description: Path to the build file.

enumValues: Automatically detect the build file (`build.rs`).

enumValues: Disable automatic detection of the build file.

title: Debug Level

description:
The `debug` setting controls the [`-C debuginfo` flag](https://doc.rust-lang.org/rustc/codegen-options/index.html#debuginfo) which controls the
amount of debug information included in the compiled binary.

enumValues: No debug info at all, default for `release` profile

enumValues: Debug info without type or variable-level information. Generates more detailed module-level info than `line-tables-only`.

enumValues: Full debug info, default for `dev` profile

enumValues: Line info directives only. For the nvptx* targets this enables [profiling](https://reviews.llvm.org/D46061). For other use cases, `line-tables-only` is the better, more compatible choice.

enumValues: Line tables only. Generates the minimal amount of debug info for backtraces with filename/line number info, but not anything else, i.e. no variable or function parameter info.

title: Dependency

$ref: #/definitions/SemVerRequirement

$ref: #/definitions/DetailedDependency

title: Detailed Dependency

description: Specify the Git branch to use in case of a [Git dependency](https://doc.rust-lang.org/cargo/reference/specifying-dependencies.html#specifying-dependencies-from-git-repositories).

description: Use the default features of the dependency.

description: List of features to activate in the dependency.

schemas: feature

description:
To depend on a library located in a `git` repository, the minimum information
you need to specify is the location of the repository with the `git` key:

```toml
[dependencies]
rand = { git = "https://github.com/rust-lang-nursery/rand" }
```

Cargo will fetch the `git` repository at this location then look for a
`Cargo.toml` for the requested crate anywhere inside the `git` repository
(not necessarily at the root - for example, specifying a member crate name
of a workspace and setting `git` to the repository containing the workspace).

Since we haven't specified any other information, Cargo assumes that
we intend to use the latest commit on the main branch to build our package.
You can combine the `git` key with the `rev`, `tag`, or `branch` keys to
specify something else. Here's an example of specifying that you want to use
the latest commit on a branch named `next`:

```toml
[dependencies]
rand = { git = "https://github.com/rust-lang-nursery/rand", branch = "next" }
```

See [Git Authentication](https://doc.rust-lang.org/cargo/appendix/git-authentication.html) for help with git authentication for private repos.

> **Note**: [crates.io](https://crates.io/) does not allow packages to be published with `git`
> dependencies (`git` [dev-dependencies](https://doc.rust-lang.org/cargo/reference/specifying-dependencies.html#development-dependencies) are ignored). See the [Multiple
> locations](https://doc.rust-lang.org/cargo/reference/specifying-dependencies.html#multiple-locations) section for a fallback alternative.

description:
Mark the dependency as optional.

Optional dependencies can be activated through features.

description:
Specify the name of the package.

When writing a `[dependencies]` section in `Cargo.toml` the key you write for a
dependency typically matches up to the name of the crate you import from in the
code. For some projects, though, you may wish to reference the crate with a
different name in the code regardless of how it's published on crates.io. For
example you may wish to:

* Avoid the need to  `use foo as bar` in Rust source.
* Depend on multiple versions of a crate.
* Depend on crates with the same name from different registries.

To support this Cargo supports a `package` key in the `[dependencies]` section
of which package should be depended on:

```toml
[package]
name = "mypackage"
version = "0.0.1"

[dependencies]
foo = "0.1"
bar = { git = "https://github.com/example/project", package = "foo" }
baz = { version = "0.1", registry = "custom", package = "foo" }
```

In this example, three crates are now available in your Rust code:

```rust
extern crate foo; // crates.io
extern crate bar; // git repository
extern crate baz; // registry `custom`
```

All three of these crates have the package name of `foo` in their own
`Cargo.toml`, so we're explicitly using the `package` key to inform Cargo that
we want the `foo` package even though we're calling it something else locally.
The `package` key, if not specified, defaults to the name of the dependency
being requested.

description:
Cargo supports **path dependencies** which are typically sub-crates that live within one repository.
Let's start off by making a new crate inside of our `hello_world` package:

```console
# inside of hello_world/
$ cargo new hello_utils
```

This will create a new folder `hello_utils` inside of which a `Cargo.toml` and
`src` folder are ready to be configured. In order to tell Cargo about this, open
up `hello_world/Cargo.toml` and add `hello_utils` to your dependencies:

```toml
[dependencies]
hello_utils = { path = "hello_utils" }
```

This tells Cargo that we depend on a crate called `hello_utils` which is found
in the `hello_utils` folder (relative to the `Cargo.toml` it's written in).

description:
To specify a dependency from a registry other than [crates.io](https://crates.io), first the
registry must be configured in a `.cargo/config.toml` file. See the [registries
documentation](https://doc.rust-lang.org/cargo/reference/registries.html) for more information. In the dependency, set the `registry` key
to the name of the registry to use.

```toml
[dependencies]
some-crate = { version = "1.0", registry = "my-registry" }
```

> **Note**: [crates.io](https://crates.io) does not allow packages to be published with
> dependencies on other registries.

description: Specify the Git revision to use in case of a [Git dependency](https://doc.rust-lang.org/cargo/reference/specifying-dependencies.html#specifying-dependencies-from-git-repositories).

description: Specify the Git tag to use in case of a [Git dependency](https://doc.rust-lang.org/cargo/reference/specifying-dependencies.html#specifying-dependencies-from-git-repositories).

title: Edition

description:
The `edition` key affects which edition your package is compiled with. Cargo
will always generate packages via [`cargo new`](https://doc.rust-lang.org/cargo/commands/cargo-new.html) with the `edition` key set to the
latest edition. Setting the `edition` key in `[package]` will affect all
targets/crates in the package, including test suites, benchmarks, binaries,
examples, etc.

title: Lto

description:
The `lto` setting controls the [`-C lto` flag](https://doc.rust-lang.org/rustc/codegen-options/index.html#lto) which controls LLVM's [link time optimizations](https://llvm.org/docs/LinkTimeOptimization.html). LTO can produce better optimized code, using
whole-program analysis, at the cost of longer linking time.

See also the [`-C linker-plugin-lto`](https://doc.rust-lang.org/rustc/codegen-options/index.html#linker-plugin-lto) `rustc` flag for cross-language LTO.

enumValues: Performs "fat" LTO which attempts to perform optimizations across all crates within the dependency graph.

enumValues:
Performs ["thin" LTO](http://blog.llvm.org/2016/06/thinlto-scalable-and-incremental-lto.html). This is similar to "fat", but takes
substantially less time to run while still achieving performance gains
similar to "fat".

enumValues:
Performs "thin local LTO" which performs "thin" LTO on the local
crate only across its [codegen units](https://doc.rust-lang.org/cargo/reference/profiles.html#codegen-units). No LTO is performed
if codegen units is 1 or [opt-level](https://doc.rust-lang.org/cargo/reference/profiles.html#opt-level) is 0.

title: Meta Build

title: Resolver

description:
A different feature resolver algorithm can be used by specifying the resolver version in Cargo.toml like this:

[package]
name = "my-package"
version = "1.0.0"
resolver = "2"

The version "1" resolver is the original resolver that shipped with Cargo up to version 1.50. The default is "2" if the root package specifies edition = "2021" or a newer edition. Otherwise the default is "1".

The version "2" resolver introduces changes in feature unification. See the features chapter for more details.

The resolver is a global option that affects the entire workspace. The resolver version in dependencies is ignored, only the value in the top-level package will be used. If using a virtual workspace, the version should be specified in the [workspace] table, for example:

[workspace]
members = ["member1", "member2"]
resolver = "2"

title: Optimization Level

description:
The `opt-level` setting controls the [`-C opt-level` flag](https://doc.rust-lang.org/rustc/codegen-options/index.html#opt-level) which controls the level
of optimization. Higher optimization levels may produce faster runtime code at
the expense of longer compiler times. Higher levels may also change and
rearrange the compiled code which may make it harder to use with a debugger.

It is recommended to experiment with different levels to find the right
balance for your project. There may be surprising results, such as level `3`
being slower than `2`, or the `"s"` and `"z"` levels not being necessarily
smaller. You may also want to reevaluate your settings over time as newer
versions of `rustc` changes optimization behavior.

See also [Profile Guided Optimization](https://doc.rust-lang.org/rustc/profile-guided-optimization.html) for more advanced optimization
techniques.

enumValues: No optimizations, also turns on [`cfg(debug_assertions)`](https://doc.rust-lang.org/cargo/reference/profiles.html#debug-assertions).

enumValues: Optimize for binary size, but also turn off loop vectorization.

title: Package

description:
The only fields required by Cargo are [`name`](https://doc.rust-lang.org/cargo/reference/manifest.html#the-name-field) and
[`version`](https://doc.rust-lang.org/cargo/reference/manifest.html#the-version-field). If publishing to a registry, the registry may
require additional fields. See the notes below and [the publishing chapter](https://doc.rust-lang.org/cargo/reference/publishing.html) for requirements for publishing to [crates.io](https://crates.io/).

required: name version

$ref: #/definitions/Authors

$ref: #/definitions/WorkspaceInheritance

description:
Disable automatic discovery of `bench` targets.

Disabling automatic discovery should only be needed for specialized
situations. For example, if you have a library where you want a *module* named
`bin`, this would present a problem because Cargo would usually attempt to
compile anything in the `bin` directory as an executable. Here is a sample
layout of this scenario:

```
├── Cargo.toml
└── src
    ├── lib.rs
    └── bin
        └── mod.rs
```

description:
Disable automatic discovery of `bin` targets.

Disabling automatic discovery should only be needed for specialized
situations. For example, if you have a library where you want a *module* named
`bin`, this would present a problem because Cargo would usually attempt to
compile anything in the `bin` directory as an executable. Here is a sample
layout of this scenario:

```
├── Cargo.toml
└── src
    ├── lib.rs
    └── bin
        └── mod.rs
```

To prevent Cargo from inferring `src/bin/mod.rs` as an executable, set
this to `false` to disable auto-discovery.

description:
Disable automatic discovery of `example` targets.

Disabling automatic discovery should only be needed for specialized
situations. For example, if you have a library where you want a *module* named
`bin`, this would present a problem because Cargo would usually attempt to
compile anything in the `bin` directory as an executable. Here is a sample
layout of this scenario:

```
├── Cargo.toml
└── src
    ├── lib.rs
    └── bin
        └── mod.rs
```

description:
Disable automatic discovery of `test` targets.

Disabling automatic discovery should only be needed for specialized
situations. For example, if you have a library where you want a *module* named
`bin`, this would present a problem because Cargo would usually attempt to
compile anything in the `bin` directory as an executable. Here is a sample
layout of this scenario:

```
├── Cargo.toml
└── src
    ├── lib.rs
    └── bin
        └── mod.rs
```

$ref: #/definitions/Build

$ref: #/definitions/Categories

description:
The `default-run` field in the `[package]` section of the manifest can be used
to specify a default binary picked by [`cargo run`](https://doc.rust-lang.org/cargo/commands/cargo-run.html). For example, when there is
both `src/bin/a.rs` and `src/bin/b.rs`:

```toml
[package]
default-run = "a"
```

$ref: #/definitions/Documentation

$ref: #/definitions/Edition

$ref: #/definitions/Exclude

$ref: #/definitions/Homepage

description: Sets whether the current package is a teapot or something else that is not capable of brewing tea.

$ref: #/definitions/Include

$ref: #/definitions/Keywords

$ref: #/definitions/License

$ref: #/definitions/LicenseFile

description:
The `links` field specifies the name of a native library that is being linked
to. More information can be found in the [`links`](https://doc.rust-lang.org/cargo/reference/build-scripts.html#the-links-manifest-key) section of the build
script guide.

```toml
[package]
# ...
links = "foo"
```

$ref: #/definitions/MetaBuild

description:
Cargo by default will warn about unused keys in `Cargo.toml` to assist in
detecting typos and such. The `package.metadata` table, however, is completely
ignored by Cargo and will not be warned about. This section can be used for
tools which would like to store package configuration in `Cargo.toml`. For
example:

```toml
[package]
name = "..."
# ...

# Metadata used when generating an Android APK, for example.
[package.metadata.android]
package-name = "my-awesome-android-app"
assets = "path/to/static"
```

description:
The package name is an identifier used to refer to the package. It is used
when listed as a dependency in another package, and as the default name of
inferred lib and bin targets.

The name must use only [alphanumeric](https://doc.rust-lang.org/std/primitive.char.html#method.is_alphanumeric) characters or `-` or `_`, and cannot be empty.
Note that [`cargo new`](https://doc.rust-lang.org/cargo/commands/cargo-new.html) and [`cargo init`](https://doc.rust-lang.org/cargo/commands/cargo-init.html) impose some additional restrictions on
the package name, such as enforcing that it is a valid Rust identifier and not
a keyword. [crates.io](https://crates.io) imposes even more restrictions, such as
enforcing only ASCII characters, not a reserved name, not a special Windows
name such as "nul", is not too long, etc.

$ref: #/definitions/Publish

$ref: #/definitions/Readme

$ref: #/definitions/Repository

$ref: #/definitions/Resolver

$ref: #/definitions/RustVersion

$ref: #/definitions/SemVer

description:
The `workspace` field can be used to configure the workspace that this package
will be a member of. If not specified this will be inferred as the first
Cargo.toml with `[workspace]` upwards in the filesystem. Setting this is
useful if the member is not inside a subdirectory of the workspace root.

```toml
[package]
# ...
workspace = "path/to/workspace/root"
```

This field cannot be specified if the manifest already has a `[workspace]`
table defined. That is, a crate cannot both be a root crate in a workspace
(contain `[workspace]`) and also be a member crate of another workspace
(contain `package.workspace`).

For more information, see the [workspaces chapter](https://doc.rust-lang.org/cargo/reference/workspaces.html).

title: Panic

description:
The `panic` setting controls the [`-C panic` flag](https://doc.rust-lang.org/rustc/codegen-options/index.html#panic) which controls which panic
strategy to use.

When set to `"unwind"`, the actual value depends on the default of the target
platform. For example, the NVPTX platform does not support unwinding, so it
always uses `"abort"`.

Tests, benchmarks, build scripts, and proc macros ignore the `panic` setting.
The `rustc` test harness currently requires `unwind` behavior. See the
[`panic-abort-tests`](https://doc.rust-lang.org/cargo/reference/unstable.html#panic-abort-tests) unstable flag which enables `abort` behavior.

Additionally, when using the `abort` strategy and building a test, all of the
dependencies will also be forced to built with the `unwind` strategy.

enum: unwind abort

enumValues:
Unwind the stack upon panic.
Terminate the process upon panic.

title: Platform

description:
You can depend on other Cargo-based crates for use in your build scripts.
Dependencies are declared through the `build-dependencies` section of the
manifest:

```toml
[build-dependencies]
cc = "1.0.3"
```

The build script **does not** have access to the dependencies listed
in the `dependencies` or `dev-dependencies` section. Build
dependencies will likewise not be available to the package itself
unless listed under the `dependencies` section as well. A package
itself and its build script are built separately, so their
dependencies need not coincide. Cargo is kept simpler and cleaner by
using independent dependencies for independent purposes.

$ref: #/definitions/Dependency

schemas: dependencies

description:
Cargo is configured to look for dependencies on [crates.io](https://crates.io) by default. Only
the name and a version string are required in this case. In [the cargo
guide](https://doc.rust-lang.org/cargo/guide/index.html), we specified a dependency on the `time` crate:

```toml
[dependencies]
time = "0.1.12"
```

The string `"0.1.12"` is a [semver](https://github.com/steveklabnik/semver#requirements) version requirement. Since this
string does not have any operators in it, it is interpreted the same way as
if we had specified `"^0.1.12"`, which is called a caret requirement.

A dependency can also be defined by a table with additional options:

```toml
[dependencies]
time = { path = "../time", version = "0.1.12" }
```

description:
The format of `[dev-dependencies]` is equivalent to `[dependencies]`:

```toml
[dev-dependencies]
tempdir = "0.3"
```

Dev-dependencies are not used when compiling
a package for building, but are used for compiling tests, examples, and
benchmarks.

These dependencies are *not* propagated to other packages which depend on this
package.

You can also have target-specific development dependencies by using
`dev-dependencies` in the target section header instead of `dependencies`. For
example:

```toml
[target.'cfg(unix)'.dev-dependencies]
mio = "0.0.1"
```

> **Note**: When a package is published, only dev-dependencies that specify a
> `version` will be included in the published crate. For most use cases,
> dev-dependencies are not needed when published, though some users (like OS
> packagers) may want to run tests within a crate, so providing a `version` if
> possible can still be beneficial.

title: Build Override

description:
Profile settings can be overridden for specific packages and build-time
crates. To override the settings for a specific package, use the `package`
table to change the settings for the named package:

```toml
# The `foo` package will use the -Copt-level=3 flag.
[profile.dev.package.foo]
opt-level = 3
```

The package name is actually a [Package ID Spec](https://doc.rust-lang.org/cargo/reference/pkgid-spec.html), so you can
target individual versions of a package with syntax such as
`[profile.dev.package."foo:2.1.0"]`.

To override the settings for all dependencies (but not any workspace member),
use the `"*"` package name:

```toml
# Set the default for dependencies.
[profile.dev.package."*"]
opt-level = 2
```

To override the settings for build scripts, proc macros, and their
dependencies, use the `build-override` table:

```toml
# Set the settings for build scripts and proc-macros.
[profile.dev.build-override]
opt-level = 3
```

> Note: When a dependency is both a normal dependency and a build dependency,
> Cargo will try to only build it once when `--target` is not specified. When
> using `build-override`, the dependency may need to be built twice, once as a
> normal dependency and once with the overridden build settings. This may
> increase initial build times.

$ref: #/definitions/Profile

title: Profile

description:
The `codegen-units` setting controls the [`-C codegen-units` flag](https://doc.rust-lang.org/rustc/codegen-options/index.html#codegen-units) which
controls how many "code generation units" a crate will be split into. More
code generation units allows more of a crate to be processed in parallel
possibly reducing compile time, but may produce slower code.

This option takes an integer greater than 0.

The default is 256 for [incremental](https://doc.rust-lang.org/cargo/reference/profiles.html#incremental) builds, and 16 for
non-incremental builds.

$ref: #/definitions/DebugLevel

description:
The `debug-assertions` setting controls the [`-C debug-assertions` flag](https://doc.rust-lang.org/rustc/codegen-options/index.html#debug-assertions) which
turns `cfg(debug_assertions)` [conditional compilation](https://doc.rust-lang.org/reference/conditional-compilation.html#debug_assertions) on or off. Debug
assertions are intended to include runtime validation which is only available
in debug/development builds. These may be things that are too expensive or
otherwise undesirable in a release build. Debug assertions enables the
[`debug_assert!` macro](https://doc.rust-lang.org/std/macro.debug_assert.html) in the standard library.

description:
The `incremental` setting controls the [`-C incremental` flag](https://doc.rust-lang.org/rustc/codegen-options/index.html#incremental) which controls
whether or not incremental compilation is enabled. Incremental compilation
causes `rustc` to to save additional information to disk which will be reused
when recompiling the crate, improving re-compile times. The additional
information is stored in the `target` directory.

The valid options are:

* `true`: enabled
* `false`: disabled

Incremental compilation is only used for workspace members and "path"
dependencies.

The incremental value can be overridden globally with the `CARGO_INCREMENTAL`
[environment variable](https://doc.rust-lang.org/cargo/reference/environment-variables.html) or the [`build.incremental`](https://doc.rust-lang.org/cargo/reference/config.html#buildincremental) config variable.

description:
The `overflow-checks` setting controls the [`-C overflow-checks` flag](https://doc.rust-lang.org/rustc/codegen-options/index.html#overflow-checks) which
controls the behavior of [runtime integer overflow](https://doc.rust-lang.org/reference/expressions/operator-expr.html#overflow). When overflow-checks are
enabled, a panic will occur on overflow.

description:
Package-specific overrides.

The package name is a [Package ID Spec](https://doc.rust-lang.org/cargo/reference/pkgid-spec.html), so you can
target individual versions of a package with syntax such as `[profile.dev.package."foo:2.1.0"]`.

description:
The `rpath` setting controls the [`-C rpath` flag](https://doc.rust-lang.org/rustc/codegen-options/index.html#rpath) which controls
whether or not [`rpath`](https://en.wikipedia.org/wiki/Rpath) is enabled.

title: Profiles

description:
Profiles provide a way to alter the compiler settings, influencing things like optimizations and debugging symbols.

Cargo has 4 built-in profiles: dev, release, test, and bench. It automatically chooses the profile based on which command is being run, the package and target that is being built, and command-line flags like --release.

title: Publish

description:
The `publish` field can be used to prevent a package from being published to a package registry (like *crates.io*) by mistake, for instance to keep a package
private in a company.

```toml
[package]
# ...
publish = false
```

The value may also be an array of strings which are registry names that are
allowed to be published to.

```toml
[package]
# ...
publish = ["some-registry-name"]
```

description: A boolean indicating whether the package can be published.

enumValues:
The package can be published.
The package cannot be published.

description: An array of registry names.

title: Readme

description:
The `readme` field should be the path to a file in the package root (relative
to this `Cargo.toml`) that contains general information about the package.
This file will be transferred to the registry when you publish. [crates.io](https://crates.io)
will interpret it as Markdown and render it on the crate's page.

```toml
[package]
# ...
readme = "README.md"
```

If no value is specified for this field, and a file named `README.md`,
`README.txt` or `README` exists in the package root, then the name of that
file will be used. You can suppress this behavior by setting this field to
`false`. If the field is set to `true`, a default value of `README.md` will
be assumed.

description:
The `readme` field should be the path to a file in the package root (relative
to this `Cargo.toml`) that contains general information about the package.

enumValues:
Use the `README.md` file.
Do not use the default `README.md` file

title: Semantic Version

description:
Cargo bakes in the concept of [Semantic Versioning](https://semver.org/), so make sure you follow some basic rules:

* Before you reach 1.0.0, anything goes, but if you make breaking changes,
    increment the minor version. In Rust, breaking changes include adding fields to
    structs or variants to enums.
* After 1.0.0, only make breaking changes when you increment the major version.
    Don't break the build.
* After 1.0.0, don't add any new public API (no new `pub` anything) in patch-level
    versions. Always increment the minor version if you add any new `pub` structs,
    traits, fields, types, functions, methods or anything else.
* Use version numbers with three numeric parts such as 1.0.0 rather than 1.0.

title: Semantic Version Requirement

description: The [version requirement](https://doc.rust-lang.org/cargo/reference/specifying-dependencies.html) of the target dependency.

title: Target

description:
The `bench` field indicates whether or not the target is benchmarked by
default by [`cargo bench`](https://doc.rust-lang.org/cargo/commands/cargo-bench.html). The default is `true` for lib, bins, and
benchmarks.

description:
The `crate-type` field defines the [crate types](https://doc.rust-lang.org/reference/linkage.html) that will be generated by the
target. It is an array of strings, allowing you to specify multiple crate
types for a single target. This can only be specified for libraries and
examples. Binaries, tests, and benchmarks are always the "bin" crate type.

The available options are `bin`, `lib`, `rlib`, `dylib`, `cdylib`,
`staticlib`, and `proc-macro`. You can read more about the different crate
types in the [Rust Reference Manual](https://doc.rust-lang.org/reference/linkage.html).

enumValues:
A runnable executable will be produced. This requires that there is a `main` function in the crate which
will be run when the program begins executing. This will link in all Rust and
native dependencies, producing a distributable binary.

enumValues:
A Rust library will be produced.
This is an ambiguous concept as to what exactly is produced because a library
can manifest itself in several forms. The purpose of this generic `lib` option
is to generate the "compiler recommended" style of library. The output library
will always be usable by rustc, but the actual type of library may change from
time-to-time. The remaining output types are all different flavors of
libraries, and the `lib` type can be seen as an alias for one of them (but the
actual one is compiler-defined).

enumValues:
A "Rust library" file will be produced. This is used as an intermediate artifact and can be thought of as a
"static Rust library". These `rlib` files, unlike `staticlib` files, are
interpreted by the compiler in future linkage. This essentially means
that `rustc` will look for metadata in `rlib` files like it looks for metadata
in dynamic libraries. This form of output is used to produce statically linked
executables as well as `staticlib` outputs.

enumValues:
A dynamic Rust library will be produced. This is different from the `lib` output type in that this forces
dynamic library generation. The resulting dynamic library can be used as a
dependency for other libraries and/or executables. This output type will
create `*.so` files on linux, `*.dylib` files on osx, and `*.dll` files on
windows.

enumValues:
A dynamic system library will be produced. This is used when compiling
a dynamic library to be loaded from another language.  This output type will
create `*.so` files on Linux, `*.dylib` files on macOS, and `*.dll` files on
Windows.

enumValues:
A static system library will be produced. This is different from other library outputs in that
the compiler will never attempt to link to `staticlib` outputs. The
purpose of this output type is to create a static library containing all of
the local crate's code along with all upstream dependencies. The static
library is actually a `*.a` archive on linux and osx and a `*.lib` file on
windows. This format is recommended for use in situations such as linking
Rust code into an existing non-Rust application because it will not have
dynamic dependencies on other Rust code.

enumValues:
The output produced is not specified, but if a `-L` path is provided to it then the
compiler will recognize the output artifacts as a macro and it can be loaded
for a program. Crates compiled with this crate type  must only export
[procedural macros](https://doc.rust-lang.org/reference/procedural-macros.html). The compiler will automatically set the `proc_macro`
[configuration option](https://doc.rust-lang.org/reference/conditional-compilation.html). The crates are always compiled with the same target
that the compiler itself was built with. For example, if you are executing
the compiler from Linux with an `x86_64` CPU, the target will be
`x86_64-unknown-linux-gnu` even if the crate is a dependency of another crate
being built for a different target.

description:
The `doc` field indicates whether or not the target is included in the
documentation generated by [`cargo doc`](https://doc.rust-lang.org/cargo/commands/cargo-doc.html) by default. The default is `true` for
libraries and binaries.

> **Note**: The binary will be skipped if its name is the same as the lib
> target.

description:
The `doctest` field indicates whether or not [documentation examples](https://doc.rust-lang.org/rustdoc/documentation-tests.html) are
tested by default by [`cargo test`](https://doc.rust-lang.org/cargo/commands/cargo-test.html). This is only relevant for libraries, it
has no effect on other sections. The default is `true` for the library.

description:
The `harness` field indicates that the [`--test` flag](https://doc.rust-lang.org/rustc/command-line-arguments.html#option-test) will be passed to
`rustc` which will automatically include the libtest library which is the
driver for collecting and running tests marked with the [`#[test]` attribute](https://doc.rust-lang.org/reference/attributes/testing.html#the-test-attribute) or benchmarks with the `#[bench]` attribute. The
default is `true` for all targets.

If set to `false`, then you are responsible for defining a `main()` function
to run tests and benchmarks.

Tests have the [`cfg(test)` conditional expression](https://doc.rust-lang.org/reference/conditional-compilation.html#test) enabled whether
or not the harness is enabled.

description:
The `name` field specifies the name of the target, which corresponds to the
filename of the artifact that will be generated. For a library, this is the
crate name that dependencies will use to reference it.

For the `[lib]` and the default binary (`src/main.rs`), this defaults to the
name of the package, with any dashes replaced with underscores. For other
[auto discovered](https://doc.rust-lang.org/cargo/reference/cargo-targets.html#target-auto-discovery) targets, it defaults to the
directory or file name.

This is required for all targets except `[lib]`.

description:
The `path` field specifies where the source for the crate is located, relative
to the `Cargo.toml` file.

If not specified, the [inferred path](https://doc.rust-lang.org/cargo/reference/cargo-targets.html#target-auto-discovery) is used based on
the target name.

description:
The `proc-macro` field indicates that the library is a [procedural macro](https://doc.rust-lang.org/book/ch19-06-macros.html)
([reference](https://doc.rust-lang.org/reference/procedural-macros.html)). This is only valid for the `[lib]`
target.

description:
The `required-features` field specifies which [features](https://doc.rust-lang.org/cargo/reference/features.html) the target needs in
order to be built. If any of the required features are not enabled, the
target will be skipped. This is only relevant for the `[[bin]]`, `[[bench]]`,
`[[test]]`, and `[[example]]` sections, it has no effect on `[lib]`.

```toml
[features]
# ...
postgres = []
sqlite = []
tools = []

[[bin]]
name = "my-pg-tool"
required-features = ["postgres", "tools"]
```

description:
The `test` field indicates whether or not the target is tested by default by
[`cargo test`](https://doc.rust-lang.org/cargo/commands/cargo-test.html). The default is `true` for lib, bins, and tests.

> **Note**: Examples are built by [`cargo test`](https://doc.rust-lang.org/cargo/commands/cargo-test.html) by default to ensure they
> continue to compile, but they are not *tested* by default. Setting `test =
> true` for an example will also build it as a test and run any
> [`#[test]`](https://doc.rust-lang.org/reference/attributes/testing.html#the-test-attribute) functions defined in the example.

title: Workspace

description:
The `[workspace]` table in `Cargo.toml` defines which packages are members of
the workspace:

```toml
[workspace]
members = ["member1", "path/to/member2", "crates/*"]
exclude = ["crates/foo", "path/to/other"]
```

An empty `[workspace]` table can be used with a `[package]` to conveniently
create a workspace with the package and all of its path dependencies.

All [`path` dependencies](https://doc.rust-lang.org/cargo/reference/specifying-dependencies.html#specifying-path-dependencies) residing in the workspace directory automatically
become members. Additional members can be listed with the `members` key, which
should be an array of strings containing directories with `Cargo.toml` files.

The `members` list also supports [globs](https://docs.rs/glob/0.3.0/glob/struct.Pattern.html) to match multiple paths, using
typical filename glob patterns like `*` and `?`.

The `exclude` key can be used to prevent paths from being included in a
workspace. This can be useful if some path dependencies aren't desired to be
in the workspace at all, or using a glob pattern and you want to remove a
directory.

An empty `[workspace]` table can be used with a `[package]` to conveniently
create a workspace with the package and all of its path dependencies.

description:
The optional `default-members` key can be specified to set the members to
operate on when in the workspace root and the package selection flags are not
used:

```toml
[workspace]
members = ["path/to/member1", "path/to/member2", "path/to/member3/*"]
default-members = ["path/to/member2", "path/to/member3/foo"]
```

When specified, `default-members` must expand to a subset of `members`.

description:
The `workspace.dependencies` table is where you define dependencies to be
inherited by members of a workspace.

Specifying a workspace dependency is similar to [package dependencies](https://doc.rust-lang.org/cargo/reference/specifying-dependencies.html) except:
- Dependencies from this table cannot be declared as `optional`
- [`features`][features] declared in this table are additive with the `features` from `[dependencies]`

You can then [inherit the workspace dependency as a package dependency](https://doc.rust-lang.org/cargo/reference/specifying-dependencies.html#inheriting-a-dependency-from-a-workspace)

Example:
```toml
# [PROJECT_DIR]/Cargo.toml
[workspace]
members = ["bar"]

[workspace.dependencies]
cc = "1.0.73"
rand = "0.8.5"
regex = { version = "1.6.0", default-features = false, features = ["std"] }
```

```toml
# [PROJECT_DIR]/bar/Cargo.toml
[package]
name = "bar"
version = "0.2.0"

[dependencies]
regex = { workspace = true, features = ["unicode"] }

[build-dependencies]
cc.workspace = true

[dev-dependencies]
rand.workspace = true
```

description:
The `exclude` key can be used to prevent paths from being included in a
workspace. This can be useful if some path dependencies aren't desired to be
in the workspace at all, or using a glob pattern and you want to remove a
directory.

description:
All [`path` dependencies] residing in the workspace directory automatically
become members. Additional members can be listed with the `members` key, which
should be an array of strings containing directories with `Cargo.toml` files.

The `members` list also supports [globs] to match multiple paths, using
typical filename glob patterns like `*` and `?`.

description:
The `workspace.metadata` table is ignored by Cargo and will not be warned
about. This section can be used for tools that would like to store workspace
configuration in `Cargo.toml`. For example:

```toml
[workspace]
members = ["member1", "member2"]

[workspace.metadata.webcontents]
root = "path/to/webproject"
tool = ["npm", "run", "build"]
# ...
```

There is a similar set of tables at the package level at
`package.metadata`. While cargo does not specify a
format for the content of either of these tables, it is suggested that
external tools may wish to use them in a consistent fashion, such as referring
to the data in `workspace.metadata` if data is missing from `package.metadata`,
if that makes sense for the tool in question.

description:
The `workspace.package` table is where you define keys that can be
inherited by members of a workspace. These keys can be inherited by
defining them in the member package with `{key}.workspace = true`.

Keys that are supported:

|                |                 |
|----------------|-----------------|
| `authors`      | `categories`    |
| `description`  | `documentation` |
| `edition`      | `exclude`       |
| `homepage`     | `include`       |
| `keywords`     | `license`       |
| `license-file` | `publish`       |
| `readme`       | `repository`    |
| `rust-version` | `version`       |

- `license-file` and `readme` are relative to the workspace root
- `include` and `exclude` are relative to your package root

Example:
```toml
# [PROJECT_DIR]/Cargo.toml
[workspace]
members = ["bar"]

[workspace.package]
version = "1.2.3"
authors = ["Nice Folks"]
description = "A short description of my package"
documentation = "https://example.com/bar"
```

```toml
# [PROJECT_DIR]/bar/Cargo.toml
[package]
name = "bar"
version.workspace = true
authors.workspace = true
description.workspace = true
documentation.workspace = true
```

title: Authors

description:
The `authors` field lists people or organizations that are considered the
"authors" of the package. The exact meaning is open to interpretation — it may
list the original or primary authors, current maintainers, or owners of the
package. These names will be listed on the crate's page on
[crates.io](https://crates.io). An optional email address may be included within angled
brackets at the end of each author.

> **Note**: [crates.io](https://crates.io) requires at least one author to be listed.

title: Categories

description:
The `categories` field is an array of strings of the categories this package
belongs to.

```toml
categories = ["command-line-utilities", "development-tools::cargo-plugins"]
```

> **Note**: [crates.io](https://crates.io) has a maximum of 5 categories. Each category should
> match one of the strings available at https://crates.io/category_slugs, and
> must match exactly.

title: Description

description:
The description is a short blurb about the package. [crates.io](https://crates.io) will display
this with your package. This should be plain text (not Markdown).

```toml
[package]
# ...
description = "A short description of my package"
```

> **Note**: [crates.io](https://crates.io) requires the `description` to be set.

title: Documentation

description:
The `documentation` field specifies a URL to a website hosting the crate's
documentation. If no URL is specified in the manifest file, [crates.io](https://crates.io) will
automatically link your crate to the corresponding [docs.rs](https://docs.rs) page.

```toml
[package]
# ...
documentation = "https://docs.rs/bitflags"
```

title: Exclude

description:
You can explicitly specify that a set of file patterns should be ignored or
included for the purposes of packaging. The patterns specified in the
`exclude` field identify a set of files that are not included, and the
patterns in `include` specify files that are explicitly included.

The patterns should be [gitignore](https://git-scm.com/docs/gitignore)-style patterns. Briefly:

- `foo` matches any file or directory with the name `foo` anywhere in the
  package. This is equivalent to the pattern `**/foo`.
- `/foo` matches any file or directory with the name `foo` only in the root of
  the package.
- `foo/` matches any *directory* with the name `foo` anywhere in the package.
- Common glob patterns like `*`, `?`, and `[]` are supported:
  - `*` matches zero or more characters except `/`.  For example, `*.html`
    matches any file or directory with the `.html` extension anywhere in the
    package.
  - `?` matches any character except `/`. For example, `foo?` matches `food`,
    but not `foo`.
  - `[]` allows for matching a range of characters. For example, `[ab]`
    matches either `a` or `b`. `[a-z]` matches letters a through z.
- `**/` prefix matches in any directory. For example, `**/foo/bar` matches the
  file or directory `bar` anywhere that is directly under directory `foo`.
- `/**` suffix matches everything inside. For example, `foo/**` matches all
  files inside directory `foo`, including all files in subdirectories below
  `foo`.
- `/**/` matches zero or more directories. For example, `a/**/b` matches
  `a/b`, `a/x/b`, `a/x/y/b`, and so on.
- `!` prefix negates a pattern. For example, a pattern of `src/**.rs` and
  `!foo.rs` would match all files with the `.rs` extension inside the `src`
  directory, except for any file named `foo.rs`.

If git is being used for a package, the `exclude` field will be seeded with
the `gitignore` settings from the repository.

```toml
[package]
# ...
exclude = ["build/**/*.o", "doc/**/*.html"]
```

```toml
[package]
# ...
include = ["src/**/*", "Cargo.toml"]
```

The options are mutually exclusive: setting `include` will override an
`exclude`. Note that `include` must be an exhaustive list of files as otherwise
necessary source files may not be included. The package's `Cargo.toml` is
automatically included.

The include/exclude list is also used for change tracking in some situations.
For targets built with `rustdoc`, it is used to determine the list of files to
track to determine if the target should be rebuilt. If the package has a
[build script](https://doc.rust-lang.org/cargo/reference/build-scripts.html) that does not emit any `rerun-if-*` directives, then the
include/exclude list is used for tracking if the build script should be re-run
if any of those files change.

title: Homepage

description:
The `homepage` field should be a URL to a site that is the home page for your
package.

```toml
[package]
# ...
homepage = "https://serde.rs/"
```

title: Keywords

description:
The `keywords` field is an array of strings that describe this package. This
can help when searching for the package on a registry, and you may choose any
words that would help someone find this crate.

```toml
[package]
# ...
keywords = ["gamedev", "graphics"]
```

> **Note**: [crates.io](https://crates.io) has a maximum of 5 keywords. Each keyword must be
> ASCII text, start with a letter, and only contain letters, numbers, `_` or
> `-`, and have at most 20 characters.

title: License

description:
The `license` field contains the name of the software license that the package
is released under.

[crates.io](https://crates.io/) interprets the `license` field as an [SPDX 2.1 license
expression](https://spdx.org/spdx-specification-21-web-version#h.jxpfx0ykyb60). The name must be a known license
from the [SPDX license list 3.6](https://github.com/spdx/license-list-data/tree/v3.6). Parentheses are not
currently supported. See the [SPDX site](https://spdx.org/license-list) for more information.

SPDX license expressions support AND and OR operators to combine multiple
licenses.

```toml
[package]
# ...
license = "MIT OR Apache-2.0"
```

Using `OR` indicates the user may choose either license. Using `AND` indicates
the user must comply with both licenses simultaneously. The `WITH` operator
indicates a license with a special exception. Some examples:

* `MIT OR Apache-2.0`
* `LGPL-2.1 AND MIT AND BSD-2-Clause`
* `GPL-2.0+ WITH Bison-exception-2.2`

If a package is using a nonstandard license, then the `license-file` field may
be specified in lieu of the `license` field.

title: LicenseFile

description:
The `license-file` field contains the path to a file
containing the text of the license (relative to this `Cargo.toml`).

```toml
[package]
# ...
license-file = "LICENSE.txt"
```

> **Note**: [crates.io](https://crates.io) requires either `license` or `license-file` to be set.

title: Repository

description:
The `repository` field should be a URL to the source repository for your
package.

```toml
[package]
# ...
repository = "https://github.com/rust-lang/cargo/"
```

title: RustVersion

description:
The `rust-version` field is an optional key that tells cargo what version of the
Rust language and compiler your package can be compiled with. If the currently
selected version of the Rust compiler is older than the stated version, cargo
will exit with an error, telling the user what version is required.

The first version of Cargo that supports this field was released with Rust 1.56.0.
In older releases, the field will be ignored, and Cargo will display a warning.

```toml
[package]
# ...
rust-version = "1.56"
```

The Rust version must be a bare version number with two or three components; it
cannot include semver operators or pre-release identifiers. Compiler pre-release
identifiers such as -nightly will be ignored while checking the Rust version.
The `rust-version` must be equal to or newer than the version that first
introduced the configured `edition`.

The `rust-version` may be ignored using the `--ignore-rust-version` option.

Setting the `rust-version` key in `[package]` will affect all targets/crates in
the package, including test suites, benchmarks, binaries, examples, etc.

title: Workspace

description: The `workspace` field allow keys to be inherited by defining them in the member package with `{key}.workspace = true`

description: A schema for Cargo.toml.

description:
[crates.io](https://crates.io) can display various badges for build status, test coverage, etc. for
each crate. All badges are optional.

- The badges pertaining to build status that are currently available are
  Appveyor, CircleCI, Cirrus CI, GitLab, Azure DevOps, Travis CI and Bitbucket
  Pipelines.
- Available badges pertaining to code test coverage are Codecov and Coveralls.
- There are also maintenance-related badges based on isitmaintained.com
  which state the issue resolution time, percent of open issues, and future
  maintenance intentions.

Most badge specifications require a `repository` key. It is expected to be in
`user/repo` format.

```toml
[badges]

# Appveyor: `repository` is required. `branch` is optional; default is `master`
# `service` is optional; valid values are `github` (default), `bitbucket`, and
# `gitlab`; `id` is optional; you can specify the appveyor project id if you
# want to use that instead. `project_name` is optional; use when the repository
# name differs from the appveyor project name.
appveyor = { repository = "...", branch = "master", service = "github" }

# Circle CI: `repository` is required. `branch` is optional; default is `master`
circle-ci = { repository = "...", branch = "master" }

# Cirrus CI: `repository` is required. `branch` is optional; default is `master`
cirrus-ci = { repository = "...", branch = "master" }

# GitLab: `repository` is required. `branch` is optional; default is `master`
gitlab = { repository = "...", branch = "master" }

# Azure DevOps: `project` is required. `pipeline` is required. `build` is optional; default is `1`
# Note: project = `organization/project`, pipeline = `name_of_pipeline`, build = `definitionId`
azure-devops = { project = "...", pipeline = "...", build="2" }

# Travis CI: `repository` in format "<user>/<project>" is required.
# `branch` is optional; default is `master`
travis-ci = { repository = "...", branch = "master" }

# Bitbucket Pipelines: `repository` is required. `branch` is required
bitbucket-pipelines = { repository = "...", branch = "master" }

# Codecov: `repository` is required. `branch` is optional; default is `master`
# `service` is optional; valid values are `github` (default), `bitbucket`, and
# `gitlab`.
codecov = { repository = "...", branch = "master", service = "github" }

# Coveralls: `repository` is required. `branch` is optional; default is `master`
# `service` is optional; valid values are `github` (default) and `bitbucket`.
coveralls = { repository = "...", branch = "master", service = "github" }

# Is it maintained resolution time: `repository` is required.
is-it-maintained-issue-resolution = { repository = "..." }

# Is it maintained percentage of open issues: `repository` is required.
is-it-maintained-open-issues = { repository = "..." }

# Maintenance: `status` is required. Available options are:
# - `actively-developed`: New features are being added and bugs are being fixed.
# - `passively-maintained`: There are no plans for new features, but the maintainer intends to
#   respond to issues that get filed.
# - `as-is`: The crate is feature complete, the maintainer does not intend to continue working on
#   it or providing support, but it works for the purposes it was designed for.
# - `experimental`: The author wants to share it with the community but is not intending to meet
#   anyone's particular use case.
# - `looking-for-maintainer`: The current maintainer would like to transfer the crate to someone
#   else.
# - `deprecated`: The maintainer does not recommend using this crate (the description of the crate
#   can describe why, there could be a better solution available or there could be problems with
#   the crate that the author does not want to fix).
# - `none`: Displays no badge on crates.io, since the maintainer has not chosen to specify
#   their intentions, potential crate users will need to investigate on their own.
maintenance = { status = "..." }
```

description:
Benchmarks provide a way to test the performance of your code using the
[`cargo bench`](https://doc.rust-lang.org/cargo/commands/cargo-bench.html) command. They follow the same structure as [tests](https://doc.rust-lang.org/cargo/reference/cargo-targets.html#tests),
with each benchmark function annotated with the `#[bench]` attribute.
Similarly to tests:

* Benchmarks are placed in the [`benches` directory](https://doc.rust-lang.org/cargo/guide/project-layout.html).
* Benchmark functions defined in libraries and binaries have access to the
  *private* API within the target they are defined in. Benchmarks in the
  `benches` directory may use the *public* API.
* [The `bench` field](https://doc.rust-lang.org/cargo/reference/cargo-targets.html#the-bench-field) can be used to define which targets
  are benchmarked by default.
* [The `harness` field](https://doc.rust-lang.org/cargo/reference/cargo-targets.html#the-harness-field) can be used to disable the
  built-in harness.

> **Note**: The [`#[bench]`
> attribute](https://doc.rust-lang.org/unstable-book/library-features/test.html) is currently
> unstable and only available on the [nightly channel](https://doc.rust-lang.org/book/appendix-07-nightly-rust.html). There are some
> packages available on [crates.io](https://crates.io/keywords/benchmark) that
> may help with running benchmarks on the stable channel, such as
> [Criterion](https://crates.io/crates/criterion).

description:
Binary targets are executable programs that can be run after being compiled.
The default binary filename is `src/main.rs`, which defaults to the name of
the package. Additional binaries are stored in the [`src/bin/`
directory](https://doc.rust-lang.org/cargo/guide/project-layout.html). The settings for each binary can be [customized](https://doc.rust-lang.org/cargo/reference/cargo-targets.html#configuring-a-target) in the `[[bin]]` tables in `Cargo.toml`.

Binaries can use the public API of the package's library. They are also linked
with the [`[dependencies]`](https://doc.rust-lang.org/cargo/reference/specifying-dependencies.html) defined in `Cargo.toml`.

You can run individual binaries with the [`cargo run`](https://doc.rust-lang.org/cargo/commands/cargo-run.html) command with the `--bin
<bin-name>` option. [`cargo install`](https://doc.rust-lang.org/cargo/commands/cargo-install.html) can be used to copy the executable to a
common location.

```toml
# Example of customizing binaries in Cargo.toml.
[[bin]]
name = "cool-tool"
test = false
bench = false

[[bin]]
name = "frobnicator"
required-features = ["frobnicate"]
```

description:
Files located under the [examples directory](https://doc.rust-lang.org/cargo/guide/project-layout.html) are example uses of the functionality provided by the library. When compiled, they are placed in the[ target/debug/examples directory](https://doc.rust-lang.org/cargo/guide/build-cache.html).

Examples can use the public API of the package's library. They are also linked with the [dependencies](https://doc.rust-lang.org/cargo/reference/specifying-dependencies.html) and [dev-dependencies](https://doc.rust-lang.org/cargo/reference/specifying-dependencies.html#development-dependencies) defined in Cargo.toml.

By default, examples are executable binaries (with a `main()` function). You
can specify the [`crate-type` field](https://doc.rust-lang.org/cargo/reference/cargo-targets.html#the-crate-type-field) to make an example
be compiled as a library:

```toml
[[example]]
name = "foo"
crate-type = ["staticlib"]
```

You can run individual executable examples with the [`cargo run`](https://doc.rust-lang.org/cargo/commands/cargo-run.html) command with
the `--example <example-name>` option. Library examples can be built with
[`cargo build`](https://doc.rust-lang.org/cargo/commands/cargo-build.html) with the `--example <example-name>` option. [`cargo install`](https://doc.rust-lang.org/cargo/commands/cargo-install.html)
with the `--example <example-name>` option can be used to copy executable
binaries to a common location. Examples are compiled by [`cargo test`](https://doc.rust-lang.org/cargo/commands/cargo-test.html) by
default to protect them from bit-rotting. Set [the `test`
field](https://doc.rust-lang.org/cargo/reference/cargo-targets.html#the-test-field) to `true` if you have `#[test]` functions in the
example that you want to run with [`cargo test`](https://doc.rust-lang.org/cargo/commands/cargo-test.html).

description:
Cargo supports features to allow expression of:

* conditional compilation options (usable through `cfg` attributes);
* optional dependencies, which enhance a package, but are not required; and
* clusters of optional dependencies, such as `postgres-all`, that would include the
  `postgres` package, the `postgres-macros` package, and possibly other packages
  (such as development-time mocking libraries, debugging tools, etc.).

A feature of a package is either an optional dependency, or a set of other
features.

main:
The library target defines a "library" that can be used and linked by other
libraries and executables. The filename defaults to `src/lib.rs`, and the name
of the library defaults to the name of the package. A package can have only
one library. The settings for the library can be [customized](https://doc.rust-lang.org/cargo/reference/cargo-targets.html#configuring-a-target) in the `[lib]`
table in `Cargo.toml`.

```toml
# Example of customizing the library in Cargo.toml.
[lib]
crate-type = ["cdylib"]
bench = false
```

description:
The `[patch]` section of `Cargo.toml` can be used to override dependencies
with other copies. The syntax is similar to the
[`[dependencies]`](https://doc.rust-lang.org/cargo/reference/specifying-dependencies.html) section.

description:
Files located under the [`tests` directory](https://doc.rust-lang.org/cargo/guide/project-layout.html) are integration
tests. When you run [`cargo test`](https://doc.rust-lang.org/cargo/commands/cargo-test.html), Cargo will compile each of these files as
a separate crate, and execute them.

Integration tests can use the public API of the package's library. They are
also linked with the [`[dependencies]`](https://doc.rust-lang.org/cargo/reference/specifying-dependencies.html) and
[`[dev-dependencies]`](https://doc.rust-lang.org/cargo/reference/specifying-dependencies.html#development-dependencies) defined in `Cargo.toml`.

If you want to share code among multiple integration tests, you can place it
in a separate module such as `tests/common/mod.rs` and then put `mod common;`
in each test to import it.

Each integration test results in a separate executable binary, and [`cargo
test`](https://doc.rust-lang.org/cargo/commands/cargo-test.html) will run them serially. In some cases this can be inefficient, as it
can take longer to compile, and may not make full use of multiple CPUs when
running the tests. If you have a lot of integration tests, you may want to
consider creating a single integration test, and split the tests into multiple
modules. The libtest harness will automatically find all of the `#[test]`
annotated functions and run them in parallel. You can pass module names to
[`cargo test`](https://doc.rust-lang.org/cargo/commands/cargo-test.html) to only run the tests within that module.

Binary targets are automatically built if there is an integration test. This
allows an integration test to execute the binary to exercise and test its
behavior. The `CARGO_BIN_EXE_<name>` [environment variable](https://doc.rust-lang.org/cargo/reference/environment-variables.html#environment-variables-cargo-sets-for-crates) is set when the
integration test is built so that it can use the [`env` macro](https://doc.rust-lang.org/std/macro.env.html) to locate the
executable.

title: Cargo.toml


description: Schema to validate Android JSON files given as input to DL-Config to generate Scan2Deploy barcodes

$id: #/properties/layout

type: object

title: Layout Schema

type: string

title: Description Schema

$id: #/properties/layout/properties/enroll

type: boolean

title: Enroll Schema

$id: #/properties/padlock

title: Padlock Schema

description: Section used to configure the staging locking feature

title: Valid-Until Schema

description: Specifies the expiration date of the barcode sequence. Device date must be synchronized/configured for expiration date to work properly.

$id: #/properties/padlock/properties/key

title: Key Schema

description: Padlock key to be used. If value doesn't match the device, the barcode is rejected. Empty string means no key.

$id: #/properties/padlock/properties/state

enum: locked unlocked

title: State Schema

description: Configures the padlock state

default: undefined

title: Hide-From-Launcher Schema

description: Indicates if Scan2Deploy should be disabled after staging is complete. Once disabled, factory reset required to reenable.

$id: #/properties/global

title: Global Schema

description: Section used to configure application scoped settings

title: Target-Path Schema

description: Base destination folder where any archive/fill will be inflated/written. Default is device internal SD-card root

title: Install-Path Schema

description: Folder where the application expects auto-installed/auto-updated APKs to be found. Default is value specified in 'target path'.

title: Update-Path Schema

description: Folder where the application expects auto-updated OTA packages to be found. Default is value specified in 'target path'.

title: Purge-Target-Path Schema

description: Indicates if target specified in 'target-path' needs to be purged (deleted) prior to inflation of the deployment archive

title: Auto-Scan Schema

description: Enables/Disables the auto-update of APKs and OTA packages

title: Download-Preinstalled Schema

description: Used to force the downgrade of pre-installed application (even System app), if required

$id: #/properties/global/properties/script

type: string array

title: Script Schema

description: A string specifying the absolute/relative path of a file, or a JSON array of strings describing the file content line-by-line. The script file will be interpreted last in staging process.

title: Items Schema

examples: SHELL am start -a android.intent.action.MAIN -n com.example.mchew.fakeapp/.MainActivity

$id: #/properties/global/properties/action

enum: none close enterprise-reset factory-reset reset

title: Action Schema

description: Specifies the final action performed by the application at the end of the staging process.

title: Backup-To-Enterprise Schema

description: Activates the enterprise backup persistence for the staging data, resulting in both the staging script and archive being copied to the enterprise partition

$id: #/properties/settings

title: Settings Schema

description: Section used to control inner device settings that typically need to be changed from the Android defaults

title: Date-Time Schema

description: String representation in RFC-1123 format of the date to be set

title: Auto-Time Schema

description: Controls the 'Date & Time' automatic date-time adjustment setting

title: Auto-Time-Zone Schema

description: Controls the 'Date & Time' automatic time-zone adjustment setting

title: Auto-Time-Server Schema

description: Address of the NTP server to be used for date-time synchronization

title: Debug-Bridge Schema

description: Controls the state of 'Android Debug Bridge'

title: Lock-Screen Schema

description: Controls the state of Android's lock-screen, requiring the user to swipe the display to unlock the device

title: Status-Bar Schema

description: Controls the display of the top status-bar. Note: hiding the status-bar will make notification disappear.

title: Navigation-Bar Schema

description: Controls the display of the bottom navigation-bar

type: integer

title: Charge-Threshold Schema

description: Indicates the charge threshold a battery exhausted device needs to reach to automatically boot when recharging

enum: NONE BOTH DATA CHARGE

title: Usb-Profile Schema

description: USB communication profile in use

default: BOTH

enum: MTP PTP CHARGING

title: Usb-Function Schema

description: USB communication function in use

default: CHARGING

$id: #/properties/network

title: Network Schema

description: Section used to configure the device Wi-Fi network

$id: #/properties/network/properties/essid

title: Essid Schema

description: Wireless network ESSID

default: tsunami

$id: #/properties/network/properties/hidden

title: Hidden Schema

description: Indicates if the wireless network is using a hidden ESSID

$id: #/properties/network/properties/mode

title: Mode Schema

description: Wireless connection mode

default: open

title: Mode-Key Schema

description: Wireless network key, if needed

title: Mode-Key-Encrypted Schema

description: Indicates if 'mode-key' is written in plain-text or encrypted with a custom encryption algorithm

enum: none peap tls ttls pwd sim aka aka-prime

title: Eap-Method Schema

description: Configures the EAP authentication method

enum: none pap mschap mschapv2 gtc

title: Eap-Phase2 Schema

description: Configures the EAP phase 2 authentication method

title: Eap-Identity Schema

description: Indicates the EAP identity

title: Eap-Anonymous-Identity Schema

description: Indicates the EAP anonymous identity, used as the unencrypted identity with certain EAP types

title: Eap-Password Schema

description: EAP password, if needed

title: Eap-Password-Encrypted Schema

description: Indicates if the 'eap-password' is encrypted with a custom encryption algorithm

title: Eap-Certificate Schema

description: Base64 representation of the EAP certificate to use

title: Proxy-Host Schema

description: Server name or IP address of the proxy to be used for HTTP/HTTPS communications

title: Proxy-Port Schema

description: Server IP port of the proxy for HTTP/HTTPS communications

$id: #/properties/network/properties/purge

title: Purge Schema

description: Indicates if any currently configured wireless network needs to be removed. Can be useful to avoid profile roaming.

title: Reconfigure Schema

description: If true, will reconfigure any existing and matching network. If false, will leave existing network untouched. Setting used when 'purge' is set to false.

title: Sleep-Policy Schema

description: Wireless sleep policy for Android's Settings.Global parameter (0-WIFI_SLEEP_POLICY_DEFAULT, 1-WIFI_SLEEP_POLICY_NEVER_WHILE_PLUGGED, 2-WIFI_SLEEP_POLICY_NEVER)

title: Frequency-Band Schema

description: Controls the frequency bands supported by the device

default: auto

title: Save-To-File Schema

description: Absolute path to the file where the current network configuration will be saved, empty string indicates network configuration won't be serialized to a file

title: Ephemeral Schema

description: If true, wireless connection profile will be used during staging process, then deleted after staging. If false, wireless connection profile will still be present after staging process.

title: Wait-For-Connection Schema

description: Indicates whether a valid Wi-Fi connection has to be waited once the network configuration is complete. Can be useful when device needs to be configured but a valid Wi-Fi connection is not ready yet.

$id: #/properties/deployment

title: Deployment Schema

description: Section can be used to download a ZIP archive from a server and inflate it to the 'target-path' folder

enum: http https

title: Scheme Schema

description: Deployment download scheme to use

default: http

$id: #/properties/deployment/properties/host

title: Host Schema

description: Host-name or internet-protocol address of the server from which the resource is to be fetched

$id: #/properties/deployment/properties/port

title: Port Schema

description: TCP/IP port to be used to contact the server

$id: #/properties/deployment/properties/path

title: Path Schema

description: Path to the server resource to download, complete with query string if needed

title: Fetch-Timeout Schema

description: The timeout value used when fetching resource from host

title: Check-Timeout Schema

description: The timeout value used when attempting to reach the host server

title: Working-Archive Schema

description: String representation of the archive path-file name, once downloaded

title: Skip-Inflation Schema

description: Instructs the application not to inflate the deployment archive once downloaded, can be useful to speed the OTA update process up

$id: #/properties/blobs

type: array

title: Blobs Schema

description: Section used to transfer binary data to newly created file on device

$id: #/properties/blobs/items

title: Items Schema

required: file content

title: File Schema

description: Path to the file to be created. Can be either absolute or relative to the global/target-path parameter value. During file de-serialization, any required (parent) path is automatically created.

title: Content Schema

description: Base64 representation of the actual file content

title: Android-Scan2Deploy Schema


vs-nesting.json

$ref: #/definitions/fileExtension

$ref: #/definitions/fileName

description: If this exist, files with an additional extension should nest under file without additional extension. Example: file.html.css nest under file.html

description: If this exists, files with "extra" extension part in the file name should nest under files without it, but having same name and last extension. Example: file.min.js nest under file.js.

description: Add nesting rules in the order to be applied by corresponding provider, where each rule entry has a form 'child: collection of potential parents'.

description: Remove specified nesting rules if they are merged from higher level nesting settings.

description: Nest files with specific extensions under other specific extensions

$ref: #/definitions/ext-ext

description: Nest specific file names under other specific file names

$ref: #/definitions/file-file

description: Nest files with specified suffixes under files with specified extensions.

$ref: #/definitions/file-ext

description: A greedy version of 'extensionToExtension' and has * as the only child key

description: Determines if this is the root nesting config file and no further inheritance is required.

description: Contains a collection of nesting rule providers specified in the order to be applied.

$ref: #/definitions/providers

title: JSON schema for Visual Studio's file nesting feature


minecraft-biome.json

description:
Spawner options for the current biome
https://minecraft.fandom.com/wiki/Custom_biome

title: swawner options

description:
A spawner for the current biome
https://minecraft.fandom.com/wiki/Custom_biome

description:
A mob namespaced entity for the current biome
https://minecraft.fandom.com/wiki/Custom_biome

description:
A mod spawn factor for the current biome
https://minecraft.fandom.com/wiki/Custom_biome

description:
A minimum mob spawn in a pack for the current biome
https://minecraft.fandom.com/wiki/Custom_biome

description:
A maximum mob spawn in a pack for the current biome
https://minecraft.fandom.com/wiki/Custom_biome

description: Configuration file defining a biome for a data pack for Minecraft

description:
Used for terrain noise generation. Biomes with positive depth are considered land, biomes with negative depth are oceans
https://minecraft.fandom.com/wiki/Custom_biome

type: number

description:
Used for terrain noise generation. Vertically stretches the terrain. Lower values produce flatter terrain
https://minecraft.fandom.com/wiki/Custom_biome

description: Controls if the current biome has precipitation

enum: none taiga extreme_hills jungle mesa plains savanna icy the_end beach forest ocean desert river swamp mushroom nether

description:
A temperature for the current biome
https://minecraft.fandom.com/wiki/Custom_biome

description:
A temperature modifier for the current biome
https://minecraft.fandom.com/wiki/Custom_biome

description:
A grass and foliage color for the current biome
https://minecraft.fandom.com/wiki/Custom_biome

description:
Spawns passive mobs as long as random value is less than this
https://minecraft.fandom.com/wiki/Custom_biome

title: effect options

description:
Effect options for the current biome
https://minecraft.fandom.com/wiki/Custom_biome

description:
A fog color
https://minecraft.fandom.com/wiki/Custom_biome

description:
Decimal value converted from Hex color to use for tree leaves and vines. If not present, the value depends on humidity and temperature
https://minecraft.fandom.com/wiki/Custom_biome

description:
A grass color
https://minecraft.fandom.com/wiki/Custom_biome

description:
A sky color
https://minecraft.fandom.com/wiki/Custom_biome

description:
A water color
https://minecraft.fandom.com/wiki/Custom_biome

description:
Decimal value converted from Hex color to use for fog
https://minecraft.fandom.com/wiki/Custom_biome

description:
A grass color modifier
https://minecraft.fandom.com/wiki/Custom_biome

title: particle options

description:
Particle options for the current biome
https://minecraft.fandom.com/wiki/Custom_biome

description:
A particle spawning frequency for the current biome
https://minecraft.fandom.com/wiki/Custom_biome

title: particle options

description:
A particle type for the current biome
https://minecraft.fandom.com/wiki/Custom_biome

description:
A particle state for the current biome
https://minecraft.fandom.com/wiki/Custom_biome

description:
A particle identifier for the current biome
https://minecraft.fandom.com/wiki/Custom_biome

description:
Particle properties for the current biome
https://minecraft.fandom.com/wiki/Custom_biome

const: item

description:
A particle namespaced identifier for the current biome
https://minecraft.fandom.com/wiki/Custom_biome

description:
A particle amount for the current biome
https://minecraft.fandom.com/wiki/Custom_biome

description:
A particle NBT data for the current biome
https://minecraft.fandom.com/wiki/Custom_biome

const: dust

description:
A dust color for the current biome
https://minecraft.fandom.com/wiki/Custom_biome

description:
A dust color component for the current biome
https://minecraft.fandom.com/wiki/Custom_biome

description:
A paricle size for the current biome
https://minecraft.fandom.com/wiki/Custom_biome

description:
A start dust color for the current biome
https://minecraft.fandom.com/wiki/Custom_biome

description:
An end dust color for the current biome
https://minecraft.fandom.com/wiki/Custom_biome

description:
A particle angle in radians for the current biome
https://minecraft.fandom.com/wiki/Custom_biome

const: vibration

description:
A namespaced identifier of the position source type for the current biome
https://minecraft.fandom.com/wiki/Custom_biome

description:
An offset from entity's feet for the current biome
https://minecraft.fandom.com/wiki/Custom_biome

const: block

description:
A block position for the current biome
https://minecraft.fandom.com/wiki/Custom_biome

description:
A position component for the current biome
https://minecraft.fandom.com/wiki/Custom_biome

const: entity

description:
A particle move duration for the current biome
https://minecraft.fandom.com/wiki/Custom_biome

const: shriek

description:
A particle delay in ticks for the current biome
https://minecraft.fandom.com/wiki/Custom_biome

description:
Sound event to use for ambient sound
https://minecraft.fandom.com/wiki/Custom_biome

title: Mood Sound

description:
Settings for mood sound
https://minecraft.fandom.com/wiki/Custom_biome

description:
Sound event to use
https://minecraft.fandom.com/wiki/Custom_biome

description:
Determines the cubic range of possible positions to play the mood sound. The player is at the center of the cubic range, and the edge length is 2 * block_search_extent + 1
https://minecraft.fandom.com/wiki/Custom_biome

title: Additions Sound

description:
Settings for additions sound
https://minecraft.fandom.com/wiki/Custom_biome

title: Tick Chance

title: Music

description:
Specific music that should be played in the biome
https://minecraft.fandom.com/wiki/Custom_biome

description:
Whether or not to replace music which is already playing
https://minecraft.fandom.com/wiki/Custom_biome

description:
The namespaced id of the configured surface builder to use
https://minecraft.fandom.com/wiki/Custom_biome

title: carvers

description:
Carvers to use for the current biome
https://minecraft.fandom.com/wiki/Custom_biome

description:
Carvers used during air generation step for the current biome
https://minecraft.fandom.com/wiki/Custom_biome

description:
A namespaced id of a configured carver for the current biome
https://minecraft.fandom.com/wiki/Custom_biome

description:
Carvers used during liquid generation step for the current biome
https://minecraft.fandom.com/wiki/Custom_biome

description:
Features for the current biome
https://minecraft.fandom.com/wiki/Custom_biome

description:
A feature for the current biome
https://minecraft.fandom.com/wiki/Custom_biome

description:
A creature spawn probability for the current biome
https://minecraft.fandom.com/wiki/Custom_biome

description:
The structures to generate in this biome
https://minecraft.fandom.com/wiki/Custom_biome

description:
The namespaced ID of a configured structure feature
https://minecraft.fandom.com/wiki/Custom_biome

title: spawners

description:
Entity spawning options for the current biome
https://minecraft.fandom.com/wiki/Custom_biome

title: spawn costs

description:
Entity identifiers for the current biome
https://minecraft.fandom.com/wiki/Custom_biome

title: entity identifier

description:
A namespaced entity identifier for the current biome
https://minecraft.fandom.com/wiki/Custom_biome

description:
A new mob maximum potential for the current biome
https://minecraft.fandom.com/wiki/Custom_biome

description:
A new mob charge for the current biome
https://minecraft.fandom.com/wiki/Custom_biome

title: Minecraft Data Pack Biome


flow.schema.json

title: Catalog

description: Each catalog source defines a portion of a Flow Catalog, by defining collections, derivations, tests, and materializations of the Catalog. Catalog sources may reference and import other sources, in order to collections and other entities that source defines.

title: JSON-Schema against which the Catalog is validated.

title: Captures of this Catalog.

target: target/collection

$ref: #/definitions/CaptureDef

title: Collections of this Catalog.

$ref: #/definitions/CollectionDef

title: Import other Flow catalog sources.

description: By importing another Flow catalog source, its collections, schemas, and derivations are bundled into the publication context of this specification. Imports are relative or absolute URLs, relative to this specification's location.

$ref: #/definitions/RelativeUrl

title: Materializations of this Catalog.

source: source/collection

$ref: #/definitions/MaterializationDef

title: Tests of this Catalog.

collection: acmeCo/collection

description: Description of the ingestion.

[A] document

another: document

description: Description of the verification.

$ref: #/definitions/TestStep

description: Settings to determine how Flow should stay abreast of ongoing changes to collections and schemas.

description: Automatically add new bindings discovered from the source.

description: Whether to automatically evolve collections and/or materialization bindings to handle changes to collections that would otherwise be incompatible with the existing catalog.

description: Capture names are paths of Unicode letters, numbers, '-', '_', or '.'. Each path component is separated by a slash '/', and a name may not begin or end in a '/'.

required: resource target

title: Whether to disable the binding

description: Disabled bindings are inactive, and not validated. They can be used to represent discovered resources that are intentionally not being captured.

title: Endpoint resource to capture from.

title: Name of the collection to capture into.

$ref: #/definitions/Collection

description: A Capture binds an external system and target (e.x., a SQL table or cloud storage bucket) from which data should be continuously captured, with a Flow collection into that captured data is ingested. Multiple Captures may be bound to a single collection, but only one capture may exist for a given endpoint and target.

required: bindings endpoint

title: Continuously keep the collection spec and schema up-to-date

$ref: #/definitions/AutoDiscover

title: Bound collections to capture from the endpoint.

$ref: #/definitions/CaptureBinding

title: Endpoint to capture from.

$ref: #/definitions/CaptureEndpoint

title: Interval of time between invocations of the capture.

description:
Configured intervals are applicable only to connectors which are unable to continuously tail their source, and which instead produce a current quantity of output and then exit. Flow will start the connector again after the given interval of time has passed.

Intervals are relative to the start of an invocation and not its completion. For example, if the interval is five minutes, and an invocation of the capture finishes after two minutes, then the next invocation will be started after three additional minutes.

title: Template for shards of this capture task.

$ref: #/definitions/ShardTemplate

description: An endpoint from which Flow will capture.

title: A Connector.

$ref: #/definitions/ConnectorConfig

description: Collection names are paths of Unicode letters, numbers, '-', '_', or '.'. Each path component is separated by a slash '/', and a name may not begin or end in a '/'.

description: Collection describes a set of related documents, where each adheres to a common schema and grouping key. Collections are append-only: once a document is added to a collection, it is never removed. However, it may be replaced or updated (either in whole, or in part) by a future document sharing its key. Each new document of a given key is "reduced" into existing documents of the key. By default, this reduction is achieved by completely replacing the previous document, but much richer reduction behaviors can be specified through the use of annotated reduction strategies of the collection schema.

required: readSchema writeSchema

$ref: #/definitions/Derivation

title: Template for journals of this collection.

$ref: #/definitions/JournalTemplate

title: Composite key of this collection.

$ref: #/definitions/CompositeKey

title: Projections and logical partitions of this collection.

$ref: #/definitions/Projection

title: Schema against which collection documents are validated and reduced on read.

$ref: #/definitions/Schema

title: Schema against which collection documents are validated and reduced on write and read.

title: Schema against which collection documents are validated and reduced on write.

description: Ordered JSON-Pointers which define how a composite key may be extracted from a collection document.

$ref: #/definitions/JsonPointer

description: A CompressionCodec may be applied to compress journal fragments before they're persisted to cloud stoage. The compression applied to a journal fragment is included in its filename, such as ".gz" for GZIP. A collection's compression may be changed at any time, and will affect newly-written journal fragments.

enum: NONE GZIP ZSTANDARD SNAPPY GZIP_OFFLOAD_DECOMPRESSION

description: Connector image and configuration specification.

required: config image

title: Configuration of the connector.

title: Image of the connector.

description: Derive specifies how a collection is derived from other collections.

required: transforms using

title: Template for shards of this derivation task.

title: Key component types of the shuffle keys used by derivation lambdas.

description: Typically you omit this and Flow infers it from your transform shuffle keys. In some circumstances, Flow may require that you explicitly tell it of your shuffled key types.

$ref: #/definitions/ShuffleType

title: Transforms which make up this derivation.

$ref: #/definitions/TransformDef

title: The selected runtime for this derivation.

$ref: #/definitions/DeriveUsing

description: A derivation runtime implementation.

title: A Connector.

title: A SQLite derivation.

$ref: #/definitions/DeriveUsingSqlite

title: A TypeScript derivation.

$ref: #/definitions/DeriveUsingTypescript

title: Ordered migrations which are used to initialize the database.

description: Migrations may be provided as an inline string, or as a relative URL to a file containing the migration SQL.

description: A URL identifying a resource, which may be a relative local path with respect to the current resource (i.e, ../path/to/flow.yaml), or may be an external absolute URL (i.e., http://example/flow.yaml).

title: TypeScript module implementing this derivation.

description: Module is either a relative URL of a TypeScript module file, or is an inline representation of a Typescript module. The module must have a exported Derivation variable which is an instance implementing the corresponding Derivation interface.

description: Field names a projection of a document location. They may include '/', but cannot begin or end with one. Many Fields are automatically inferred by Flow from a collection JSON Schema, and are the JSON Pointer of the document location with the leading '/' removed. User-provided Fields which act as a logical partitions are restricted to Unicode letters, numbers, '-', '_', or '.'

description: A FragmentTemplate configures how journal fragment files are produced as part of a collection.

compressionCodec: ZSTANDARD

title: Codec used to compress Journal Fragments.

$ref: #/definitions/CompressionCodec

title: Maximum flush delay before in-progress fragments are closed and persisted

description: into cloud storage. Intervals are converted into uniform time segments: 24h will "roll" all fragments at midnight UTC every day, 1h at the top of every hour, 15m a :00, :15, :30, :45 past the hour, and so on. If not set, then fragments are not flushed on time-based intervals.

title: Desired content length of each fragment, in megabytes before compression.

description: When a collection journal fragment reaches this threshold, it will be closed off and pushed to cloud storage. If not set, a default of 512MB is used.

title: Duration for which historical fragments of a collection should be kept.

description: If not set, then fragments are retained indefinitely.

description: A source collection and details of how it's read.

title: Name of the collection to be read.

title: Upper bound date-time for documents which should be processed.

description: Source collection documents published after this date-time are filtered. `notAfter` is *only* a filter. Updating its value will not cause Flow to re-process documents that have already been read. Optional. Default is to process all documents.

format: date-time

title: Lower bound date-time for documents which should be processed.

description: Source collection documents published before this date-time are filtered. `notBefore` is *only* a filter. Updating its value will not cause Flow to re-process documents that have already been read. Optional. Default is to process all documents.

title: Selector over partition of the source collection to read.

a_partition: A B

$ref: #/definitions/PartitionSelector

description: A JournalTemplate configures the journals which make up the physical partitions of a collection.

title: Fragment configuration of collection journals.

$ref: #/definitions/FragmentTemplate

description: JSON Pointer which identifies a location in a document.

description: Materialization names are paths of Unicode letters, numbers, '-', '_', or '.'. Each path component is separated by a slash '/', and a name may not begin or end in a '/'.

required: resource source

title: Whether to disable the binding

description: Disabled bindings are inactive, and not validated.

title: Selected projections for this materialization.

title: Priority applied to documents processed by this binding.

description:
When all bindings are of equal priority, Flow processes documents according to their associated publishing time, as encoded in the document UUID.

However, when one binding has a higher priority than others, then *all* ready documents are processed through the binding before *any* documents of other bindings are processed.

title: Endpoint resource to materialize into.

title: The collection to be materialized.

description: A Materialization binds a Flow collection with an external system & target (e.x, a SQL table) into which the collection is to be continuously materialized.

title: Bound collections to materialize into the endpoint.

title: Endpoint to materialize into.

title: Template for shards of this materialization task.

title: Automatically materialize new bindings from a named capture

description: An Endpoint connector used for Flow materializations.

title: A Connector.

description: MaterializationFields defines a selection of projections to materialize, as well as optional per-projection, driver-specific configuration.

title: Fields to exclude.

description: This removes from recommended projections, where enabled.

title: Fields to include.

description: This supplements any recommended fields, where enabled. Values are passed through to the driver, e.x. for customization of the driver's schema generation or runtime behavior with respect to the field.

title: Should recommended projections for the endpoint be used?

description: Partition selectors identify a desired subset of the available logical partitions of a collection.

description: Partition field names and values which are excluded from the source collection. Any documents matching *any one* of the partition values will be excluded.

description: Partition field names and corresponding values which must be matched from the Source collection. Only documents having one of the specified values across all specified partition names will be matched. For example, source: [App, Web] region: [APAC] would mean only documents of 'App' or 'Web' source and also occurring in the 'APAC' region will be processed.

description: Projections are named locations within a collection document which may be used for logical partitioning or directly exposed to databases into which collections are materialized.

title: Location of this projection.

title: Is this projection a logical partition?

description:
A schema is a draft 2020-12 JSON Schema which validates Flow documents. Schemas also provide annotations at document locations, such as reduction strategies for combining one document into another.

Schemas may be defined inline to the catalog, or given as a relative or absolute URI. URIs may optionally include a JSON fragment pointer that locates a specific sub-schema therein.

For example, "schemas/marketing.yaml#/$defs/campaign" would reference the schema at location {"$defs": {"campaign": ...}} within ./schemas/marketing.yaml.

description: A ShardTemplate configures how shards process a catalog task.

title: Disable processing of the task's shards.

title: Number of hot standbys to keep for each task shard.

description: Hot standbys of a shard actively replicate the shard's state to another machine, and are able to be quickly promoted to take over processing for the shard should its current primary fail. If not set, then no hot standbys are maintained. EXPERIMENTAL: this field MAY be removed.

title: Log level of this tasks's shards.

description: Log levels may currently be "error", "warn", "info", "debug", or "trace". If not set, the effective log level is "info".

title: Maximum duration of task transactions.

description: This duration upper-bounds the amount of time during which a transaction may process documents before it must flush and commit. It may run for less time if there aren't additional ready documents for it to process. If not set, the maximum duration defaults to five minutes for materializations, and one second for captures and derivations. EXPERIMENTAL: this field MAY be removed.

title: Minimum duration of task transactions.

description: This duration lower-bounds the amount of time during which a transaction must process documents before it must flush and commit. It may run for more time if additional documents are available. The default value is zero seconds. Larger values may result in more data reduction, at the cost of more latency. EXPERIMENTAL: this field MAY be removed.

title: Size of the reader channel used for decoded documents.

description: Larger values are recommended for tasks having more than one shard split and long, bursty transaction durations. If not set, a reasonable default (currently 4,096) is used. EXPERIMENTAL: this field is LIKELY to be removed.

title: Size of the ring buffer used to sequence documents for exactly-once semantics.

description: The ring buffer is a performance optimization only: catalog tasks will replay portions of journals as needed when messages aren't available in the buffer. It can remain small if upstream task transactions are small, but larger transactions will achieve better performance with a larger ring. If not set, a reasonable default (currently 65,536) is used. EXPERIMENTAL: this field is LIKELY to be removed.

description: A Shuffle specifies how a shuffling key is to be extracted from collection documents.

title: A Document may be shuffled to any task shard.

description: Use 'any' if your transformation does not rely on internal task state, or if your derivation is not intended to scale beyond a single shard.

title: Key which identifies fields of sourced documents to extract and shuffle upon.

title: Lambda which extracts a shuffle key from the sourced documents of this transform.

description: Lambdas may be provided inline, or as a relative URL to a file containing the lambda.

description: Type of a shuffled key component.

description: Test names are paths of Unicode letters, numbers, '-', '_', or '.'. Each path component is separated by a slash '/', and a name may not begin or end in a '/'.

description: A test step describes either an "ingest" of document fixtures into a collection, or a "verify" of expected document fixtures from a collection.

description: Description of the ingestion.

description: Description of the verification.

description: Ingest document fixtures into a collection.

description: Verify the contents of a collection match a set of document fixtures.

description: An ingestion test step ingests document fixtures into the named collection.

description: Description of the ingestion.

title: Name of the collection into which the test will ingest.

title: Description of this test ingestion.

title: Documents to ingest.

description: Each document must conform to the collection's schema.

description: A verification test step verifies that the contents of the named collection match the expected fixtures, after fully processing all preceding ingestion test steps.

description: Description of the verification.

title: Collection from which the test will verify.

title: Description of this test verification.

title: Documents to verify.

description: Each document may contain only a portion of the matched document's properties, and any properties present in the actual document but not in this document fixture are ignored. All other values must match or the test will fail.

description: Transform names are Unicode letters, numbers, '-', '_', or '.'.

description: A Transform reads and shuffles documents of a source collection, and processes each document through either one or both of a register "update" lambda and a derived document "publish" lambda.

title: Whether to disable this transform.

description: Disabled transforms are completely ignored at runtime and are not validated.

title: Lambda applied to the sourced documents of this transform.

title: Name of this transformation.

description: The names of transforms within a derivation must be unique and stable.

title: Priority applied to documents processed by this transform.

description:
When all transforms are of equal priority, Flow processes documents according to their associated publishing time, as encoded in the document UUID.

However, when one transform has a higher priority than others, then *all* ready documents are processed through the transform before *any* documents of other transforms are processed.

title: Delay applied to documents processed by this transform.

description: Delays are applied as an adjustment to the UUID clock encoded within each document, which is then used to impose a relative ordering of all documents read by this derivation. This means that read delays are applied in a consistent way, even when back-filling over historical documents. When caught up and tailing the source collection, delays also "gate" documents such that they aren't processed until the current wall-time reflects the delay.

title: Shuffle by which source documents are mapped to processing shards.

title: Source collection read by this transform.


bukkit-plugin.json

description: Optional command attributes.

description: A user-friendly description for a command.

description: Alternate command names a user may use instead.

description: The permission required to use the command.

description: A no-permission message.

description: A short description of how to use this command.

description: Optional permission attributes.

description: A short description of what this permission allows.

description: The default state for the permission.

$ref: #/definitions/default-permission

description: Allows other permissions to be set as a relation to the parent permission.

type: array object

type: boolean object

$ref: #/definitions/permission

type: string boolean

default: op

description: The unique name of plugin.

$ref: #/definitions/plugin-name

description: The plugin's initial class file.

description: A plugin revision identifier.

type: string number

description: Human readable plugin summary.

description: The plugin author.

description: The plugin contributors.

title: Website

description: The URL to the plugin's site

format: uri

description: The token to prefix plugin log entries.

description: Set to true if this plugin uses a database.

description: The phase of server-startup this plugin will load during.

enum: STARTUP POSTWORLD

default: POSTWORLD

description: Other required plugins.

description: Other plugins that add functionality.

description: A list of plugins should be loaded after this plugin.

description: The commands the plugin will register

$ref: #/definitions/command

description: The permissions the plugin will register

description: Gives the default default state of permissions registered for the plugin.

description: The concepts that the plugin acknowledges.

description: Gives the API version which this plugin is designed to support.

description: A list of libraries the server should download and supply to the plugin when loading it.

description: A single server provided library. This library can be used during runtime without being shaded into the plugin jar.

required: name main version

title: JSON schema for Bukkit Plugin YAML