dmax: Cargo Dependency Updater
Status: spattk has picked up, the repo is fifthtry/dmax.
dmax is a tool I am proposing to solve some of my problems when
working on rust projects.
We have two main problems: workspace version mismatch, and difficulty of updating crate versions.
If you are working on a rust project, not a simple library, then often
you will break your code into multiple crates, and workspace feature
so each crate in your project uses a common
target folder, and share
Version Mismatch: Problem is if use some dependency, say
multiple crates in our workspace, its not easy to ensure that each
crate is specifying the exact same version number. In majority of cases
Cargo/Rust will be able to handle different version numbers in
different crates, but in general its not a good idea as multiple
versions of diesel would be downloaded and compiled increasing the
build time. And further in some cases, especially if traits are
involved, having more than one version of some common dependency across
crates will lead to either compilation issue or logic issues (eg if
some crate has “global” data, and more than one versions of that crate
Difficulty of updating crate versions: If you project starts to grow large and old, a lot of your dependencies will keep on changing, and will have incompatible versions. Our goal is generally keep up with latest version of your dependencies, but it starts becoming hard if not each dependency is updating.
It becomes a really hard problem to figure out a set of versions for which everything compiles, so for we will have to do a search with each possible combination of versions, and finding an optimal version where everything still compiles.
dmax is a dual purpose tool. It stores versions of each package in a
crate-versions.toml, and auto update
files in your
dmax also can generate
crate-versions.toml with updated versions
where everything compiles.
As part of update to latest versions we have to update version
Cargo.toml for every crate in current workspace. This
will also need hints, eg for some crates we may be okay to have more
than one versions, but some other crates must have exactly the same
version in every (as Rust sometimes can’t handle different versions of
crates, it treats traits etc in every version as different traits for
There is no such tool where we can specify such hints etc. So the
format of proposed
crate-versions.toml must be handleable by both
Cargo.toml creator, and dependency searcher.
We should be able to specify version of each dependency workspace wide. We should also be able to override versions on dependencies for specific creates in the workspace.
[dependencies] colored = "1" [dependencies:fifthtry_db] colored = "0.1" [colored] allow_multiple_versions: true
It has key
[dependencies], which lists version for each dependency in
exactly the same format accepted by
It also have crate specific dependency overrides,
[dependencies:fifthtry_db] for example. Here we are saying all the
crates in our workspace will use
colored at version “1”, but crate
fifthtry_db will use “0.1”.
We have also specified
this configuration would not have been accepted.
We can specify
maximum_version too for any
dependency to help auto updater.
For each crate that is part of your workspace, it will look at all
dependencies, and set the version number to what is in
crate-versions.toml leaving all other keys intact.
fifthtry/dmax repo we have
folder contains all our test cases. We have a test runner that
goes through each of the folders in
tests folder and executes
our binary inside the input folder, and then compares the input
folder with output folder. If the input folder becomes identical
to output folder after binary has run, test is considered passing.