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.

Why Do We Need dmax?

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 a common Cargo.lock file.

Version Mismatch: Problem is if use some dependency, say diesel from 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 are used).

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.

What Is dmax?

dmax is a dual purpose tool. It stores versions of each package in a master file crate-versions.toml, and auto update Cargo.toml files in your cargo workspace.

dmax also can generate crate-versions.toml with updated versions where everything compiles.

Why Are We Merging Two Tools Into One?

As part of update to latest versions we have to update version information in 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 example).

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.

How does crate-versions.toml look like?

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.

colored = "1"

colored = "0.1"

allow_multiple_versions: true

It has key [dependencies], which lists version for each dependency in exactly the same format accepted by Cargo.toml.

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 allow_multiple_versions for [colored], else this configuration would not have been accepted.

We can specify minimum_version and maximum_version too for any dependency to help auto updater.

How Does It Update Cargo.toml files?

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.

How Would Auto Updater Work?


How Do We Test dmax?

In the fifthtry/dmax repo we have tests folder. This 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.

Table Of Content

Immobile v2


Rust: Or Type

Project Primer

Link Log

Oct 2020

August 2020

July 2020

June 2020

May 2020

April 2020

March 2020

February 2020

January 2020


Books Have Read / Recommend

Product Management Books

Badass: Making Users Awesome


Five Cs of An Organisation

Success and failure of encryption

Open Source

Observer: Observability for Rust

Realm: Web Development Framework Using Rust and Elm

MartD: Server To Browser Messages

On Writing And Formats Of Written Communications

Rust Stuff

fbt: Folder Based Test-Runner

dmax: Cargo Dependency Updater

Rust feature flags

Why is diesel not compatible with async?

Making Postgres Only Diesel Code To Also Support Sqlite

Rust Git2’s Concepts

Git Hash And Build Date In Rust Build

Systray Only Native App In Rust

Software and Tools I Use Often


DNS Over HTTPS Controversy

The Patel Motel Cartel

Standalone Complex


January 2020

Word Of The Day





Nix On OSX Catalina

Postgres: WAL / Logical Decoding

Postgres: Listen-Notify



Go All The Way

SSH Commands



SHA256 vs SHA224

Pronouns Bad


Web Components

Early Return