renovate/lib/manager/cargo
2019-07-15 11:04:05 +02:00
..
artifacts.js feat(typescript): convert logger to typescript (#3671) 2019-07-15 11:04:05 +02:00
extract.js feat(typescript): convert logger to typescript (#3671) 2019-07-15 11:04:05 +02:00
index.js refactor: getArtifacts -> updateArtifacts 2019-06-09 08:18:41 +02:00
readme.md docs: add implementation status to manager readme’s 2019-03-07 12:10:57 +01:00
update.js feat(typescript): convert logger to typescript (#3671) 2019-07-15 11:04:05 +02:00

Overview

Name of package manager

Cargo


Implementation status

Beta


What language does this support?

Rust


Does that language have other (competing?) package managers?

No

Package File Detection

What type of package files and names does it use?

It uses exclusively Cargo.toml files.


What fileMatch pattern(s) should be used?

Cargo.toml


Is it likely that many users would need to extend this pattern for custom file names?

No.


Is the fileMatch pattern likely to get many "false hits" for files that have nothing to do with package management?

No.

Parsing and Extraction

It is possible to have local dependencies, by specifying a file path.


Is there reason why package files need to be parsed together (in serial) instead of independently?

No a single Cargo.toml file specifies a single package.


What format/syntax is the package file in? e.g. JSON, TOML, custom?

TOML


How do you suggest parsing the file? Using an off-the-shelf parser, using regex, or can it be custom-parsed line by line?

Cargo.toml files are custom-parsed line by line.


Does the package file structure distinguish between different "types" of dependencies? e.g. production dependencies, dev dependencies, etc?

There are [build-dependencies], [dev-dependencies], and [dependencies] sections. Build dependencies are only required at compile time by the build script see reference. Dev dependencies are only required by package's tests and examples see reference. All these dependency types are treated similarly.


List all the sources/syntaxes of dependencies that can be extracted:

Normal dependencies of the format:

[dependencies]
dep1 = "1.2.3"
dep2 = "=2.3.4"

Inline table dependencies:

[dependencies]
dep1 = { version = "1.2.3", path = "./foo/bar/" }
dep2 = { default-features = false, version = "=2.3.4" }

Standard table dependencies:

[dependencies.dep1]
version = "5.2.8"
default-features = false # Comment
features = ["feat1", "feat2"]

Describe which types of dependencies above are supported and which will be implemented in future:

All 3 possible syntaxes of dependencies are supported by the existing extractPackageFile function. Different types of dependencies [dev-dependencies], [build-dependencies], and [dependencies] are treated the same.

Versioning

What versioning scheme do the package files use?

Semantic versioning.


Does this versioning scheme support range constraints, e.g. ^1.0.0 or 1.x?

Yes.


Is this package manager used for applications, libraries, or both? If both, is there a way to tell which is which?

Both. Libraries have a lib.rs file in src directory and no main.rs, binaries must have a main.rs file in src.


If ranges are supported, are there any cases when Renovate should pin ranges to exact versions if rangeStrategy=auto?

It isn't clear yet. NOTE: A cargo version like 1.3.4 is equivalent to npm version of ^1.3.4, so pinning to an exact version would require setting version to =1.3.4

Lookup

Is a new datasource required? Provide details

New crate versions can be fetched from crates.io.


Will users need the capability to specify a custom host/registry to look up? Can it be found within the package files, or within other files inside the repository, or would it require Renovate configuration?

Cargo supports dependencies hosted as git repositories at custom URL, the url is specified like:

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

see reference


Do the package files contain any "constraints" on the parent language (e.g. supports only v3.x of Python) or platform (Linux, Windows, etc) that should be used in the lookup procedure?

It is possible to have platform specific dependencies, but it doesn't affect the lookup procedure.

see reference


Will users need the ability to configure language or other constraints using Renovate config?

Cargo only deals with Rust projects.

Artifacts

Are lock files or checksum files used? Mandatory?

Yes, lock files are used, and checksums are recorded in lock files. When a crate is built a Cargo.lock file is always generated.

see reference


If so, what tool and exact commands should be used if updating 1 or more package versions in a dependency file?

Update dep1:

cargo update -p dep1

Update all dependencies:

cargo update

If applicable, describe how the tool maintains a cache and if it can be controlled via CLI or env? Do you recommend the cache be kept or disabled/ignored?

Cargo shares build artifacts among all the packages of a single workspace. Today, Cargo does not share build results across different workspaces, but a similar result can be achieved by using a third party tool, sccache. see reference


If applicable, what command should be used to generate a lock file from scratch if you already have a package file? This will be used for "lock file maintenance".

cargo update

Other

Is there anything else to know about this package manager?

cargo update or a cargo update -p dep1 command updates Cargo.lock file in current crate inplace.