Struct ToolUv 

pub struct ToolUv {

    pub sources: Option<ToolUvSources>,
    pub index: Option<Vec<Index>>,
    pub workspace: Option<ToolUvWorkspace>,
    pub managed: Option<bool>,
    pub package: Option<bool>,
    pub default_groups: Option<DefaultGroups>,
    pub dependency_groups: Option<ToolUvDependencyGroups>,
    pub dev_dependencies: Option<Vec<Requirement<VerbatimParsedUrl>>>,
    pub override_dependencies: Option<Vec<Requirement<VerbatimParsedUrl>>>,
    pub exclude_dependencies: Option<Vec<PackageName>>,
    pub constraint_dependencies: Option<Vec<Requirement<VerbatimParsedUrl>>>,
    pub build_constraint_dependencies: Option<Vec<Requirement<VerbatimParsedUrl>>>,
    pub environments: Option<SupportedEnvironments>,
    pub required_environments: Option<SupportedEnvironments>,
    pub conflicts: Option<SchemaConflicts>,
    pub build_backend: Option<BuildBackendSettingsSchema>,
}

Fields

sources: Option<ToolUvSources>

The sources to use when resolving dependencies.

tool.uv.sources enriches the dependency metadata with additional sources, incorporated during development. A dependency source can be a Git repository, a URL, a local path, or an alternative registry.

See Dependencies for more.

index: Option<Vec<Index>>

The indexes to use when resolving dependencies.

Accepts either a repository compliant with PEP 503 (the simple repository API), or a local directory laid out in the same format.

Indexes are considered in the order in which they’re defined, such that the first-defined index has the highest priority. Further, the indexes provided by this setting are given higher priority than any indexes specified via index_url or extra_index_url. uv will only consider the first index that contains a given package, unless an alternative index strategy is specified.

If an index is marked as explicit = true, it will be used exclusively for the dependencies that select it explicitly via [tool.uv.sources], as in:

[[tool.uv.index]]
name = "pytorch"
url = "https://download.pytorch.org/whl/cu121"
explicit = true

[tool.uv.sources]
torch = { index = "pytorch" }

If an index is marked as default = true, it will be moved to the end of the prioritized list, such that it is given the lowest priority when resolving packages. Additionally, marking an index as default will disable the PyPI default index.

workspace: Option<ToolUvWorkspace>

The workspace definition for the project, if any.

managed: Option<bool>

Whether the project is managed by uv. If false, uv will ignore the project when uv run is invoked.

package: Option<bool>

Whether the project should be considered a Python package, or a non-package (“virtual”) project.

Packages are built and installed into the virtual environment in editable mode and thus require a build backend, while virtual projects are not built or installed; instead, only their dependencies are included in the virtual environment.

Creating a package requires that a build-system is present in the pyproject.toml, and that the project adheres to a structure that adheres to the build backend’s expectations (e.g., a src layout).

default_groups: Option<DefaultGroups>

The list of dependency-groups to install by default.

Can also be the literal "all" to default enable all groups.

dependency_groups: Option<ToolUvDependencyGroups>

Additional settings for dependency-groups.

Currently this can only be used to add requires-python constraints to dependency groups (typically to inform uv that your dev tooling has a higher python requirement than your actual project).

This cannot be used to define dependency groups, use the top-level [dependency-groups] table for that.

dev_dependencies: Option<Vec<Requirement<VerbatimParsedUrl>>>

The project’s development dependencies.

Development dependencies will be installed by default in uv run and uv sync, but will not appear in the project’s published metadata.

Use of this field is not recommend anymore. Instead, use the dependency-groups.dev field which is a standardized way to declare development dependencies. The contents of tool.uv.dev-dependencies and dependency-groups.dev are combined to determine the final requirements of the dev dependency group.

override_dependencies: Option<Vec<Requirement<VerbatimParsedUrl>>>

Overrides to apply when resolving the project’s dependencies.

Overrides are used to force selection of a specific version of a package, regardless of the version requested by any other package, and regardless of whether choosing that version would typically constitute an invalid resolution.

While constraints are additive, in that they’re combined with the requirements of the constituent packages, overrides are absolute, in that they completely replace the requirements of any constituent packages.

Including a package as an override will not trigger installation of the package on its own; instead, the package must be requested elsewhere in the project’s first-party or transitive dependencies.

!!! note In uv lock, uv sync, and uv run, uv will only read override-dependencies from the pyproject.toml at the workspace root, and will ignore any declarations in other workspace members or uv.toml files.

exclude_dependencies: Option<Vec<PackageName>>

Dependencies to exclude when resolving the project’s dependencies.

Excludes are used to prevent a package from being selected during resolution, regardless of whether it’s requested by any other package. When a package is excluded, it will be omitted from the dependency list entirely.

Including a package as an exclusion will prevent it from being installed, even if it’s requested by transitive dependencies. This can be useful for removing optional dependencies or working around packages with broken dependencies.

!!! note In uv lock, uv sync, and uv run, uv will only read exclude-dependencies from the pyproject.toml at the workspace root, and will ignore any declarations in other workspace members or uv.toml files.

constraint_dependencies: Option<Vec<Requirement<VerbatimParsedUrl>>>

Constraints to apply when resolving the project’s dependencies.

Constraints are used to restrict the versions of dependencies that are selected during resolution.

Including a package as a constraint will not trigger installation of the package on its own; instead, the package must be requested elsewhere in the project’s first-party or transitive dependencies.

!!! note In uv lock, uv sync, and uv run, uv will only read constraint-dependencies from the pyproject.toml at the workspace root, and will ignore any declarations in other workspace members or uv.toml files.

build_constraint_dependencies: Option<Vec<Requirement<VerbatimParsedUrl>>>

Constraints to apply when solving build dependencies.

Build constraints are used to restrict the versions of build dependencies that are selected when building a package during resolution or installation.

Including a package as a constraint will not trigger installation of the package during a build; instead, the package must be requested elsewhere in the project’s build dependency graph.

!!! note In uv lock, uv sync, and uv run, uv will only read build-constraint-dependencies from the pyproject.toml at the workspace root, and will ignore any declarations in other workspace members or uv.toml files.

environments: Option<SupportedEnvironments>

A list of supported environments against which to resolve dependencies.

By default, uv will resolve for all possible environments during a uv lock operation. However, you can restrict the set of supported environments to improve performance and avoid unsatisfiable branches in the solution space.

These environments will also be respected when uv pip compile is invoked with the --universal flag.

required_environments: Option<SupportedEnvironments>

A list of required platforms, for packages that lack source distributions.

When a package does not have a source distribution, it’s availability will be limited to the platforms supported by its built distributions (wheels). For example, if a package only publishes wheels for Linux, then it won’t be installable on macOS or Windows.

By default, uv requires each package to include at least one wheel that is compatible with the designated Python version. The required-environments setting can be used to ensure that the resulting resolution contains wheels for specific platforms, or fails if no such wheels are available.

While the environments setting limits the set of environments that uv will consider when resolving dependencies, required-environments expands the set of platforms that uv must support when resolving dependencies.

For example, environments = ["sys_platform == 'darwin'"] would limit uv to solving for macOS (and ignoring Linux and Windows). On the other hand, required-environments = ["sys_platform == 'darwin'"] would require that any package without a source distribution include a wheel for macOS in order to be installable.

conflicts: Option<SchemaConflicts>

Declare collections of extras or dependency groups that are conflicting (i.e., mutually exclusive).

It’s useful to declare conflicts when two or more extras have mutually incompatible dependencies. For example, extra foo might depend on numpy==2.0.0 while extra bar depends on numpy==2.1.0. While these dependencies conflict, it may be the case that users are not expected to activate both foo and bar at the same time, making it possible to generate a universal resolution for the project despite the incompatibility.

By making such conflicts explicit, uv can generate a universal resolution for a project, taking into account that certain combinations of extras and groups are mutually exclusive. In exchange, installation will fail if a user attempts to activate both conflicting extras.

build_backend: Option<BuildBackendSettingsSchema>

Configuration for the uv build backend.

Note that those settings only apply when using the uv_build backend, other build backends (such as hatchling) have their own configuration.

Trait Implementations

impl Clone for ToolUv

fn clone(&self) -> ToolUv

Returns a duplicate of the value.

fn clone_from(&mut self, source: &Self)

Performs copy-assignment from source.

impl Debug for ToolUv

fn fmt(&self, f: &mut Formatter<'_>) -> Result

Formats the value using the given formatter.

impl<'de> Deserialize<'de> for ToolUv

fn deserialize<__D>(__deserializer: __D) -> Result<Self, __D::Error>

where __D: Deserializer<'de>,

Deserialize this value from the given Serde deserializer.

impl OptionsMetadata for ToolUv

fn record(visit: &mut dyn Visit)

Visits the options metadata of this object by calling visit for each option.

fn documentation() -> Option<&'static str>

fn metadata() -> OptionSet

where Self: Sized + 'static,

Returns the extracted metadata.

impl PartialEq for ToolUv

fn eq(&self, other: &ToolUv) -> bool

Tests for self and other values to be equal, and is used by ==.

fn ne(&self, other: &Rhs) -> bool

Tests for !=. The default implementation is almost always sufficient, and should not be overridden without very good reason.

impl Eq for ToolUv

impl StructuralPartialEq for ToolUv