Rust: Questdb-rs crate incompatible with latest ureq 2.10.1 crate

[jhaand]

Actions: Compile program with cargo using the crate ureq 2.10.1 and questdb-rs 4.0.3.

Observed: Compilation crashes with the following logging:

   Updating crates.io index
error: failed to select a version for `ureq`.
    ... required by package `questdb-rs v4.0.3`
    ... which satisfies dependency `questdb-rs = "^4.0.3"` of package `energy_reader v0.1.0 (/home/jhaand/code/energy_reader)`
versions that meet the requirements `=2.9` are: 2.9.7, 2.9.6, 2.9.5, 2.9.4, 2.9.3, 2.9.2, 2.9.1, 2.9.0

all possible versions conflict with previously selected packages.

  previously selected package `ureq v2.10.1`
    ... which satisfies dependency `ureq = "^2.10.1"` of package `energy_reader v0.1.0 (/home/jhaand/code/energy_reader)`

failed to select a version for `ureq` which could resolve this conflict

Expected: Able to uses latest stable version of the ureq crate. (2.10.1)

Workaround: Use an version 2.9.7 of the ureq crate. Note: ureq 3.0.0 will be released shortly.

reference: https://gitlab.com/jhaand/energy_reader

[amunra]

Hi Jelle, It's a well-known pain point.

Background

We've pinned the dependency due to incompatibilities that we've had in the past with the ureq crate not respecting semantic versioning correctly when it comes to its exposed rustls APIs (which we use). We've done this to avoid having our crate break with downstream user crates, such as yours.

Details on the mechanics

Specifically:

• ureq == 2.9.x depends on rustls >= 0.22.4.
• ureq == 2.10.x depends on rustls >= 0.23.5.

Note that since rustls hasn't reached 1.x yet, from a semantic versioning point of view, each minor release is effectively a major release, i.e. the new rustls version that ureq depends on introduces breaking API changes.

In effect, ureq does not respect semantic versioning correctly by exposing different major versions of rustls within its minor version releases.

Why Rust does not compile both versions side-by-side

One might expect that Cargo would compile both versions, but it does not. This is beause this feature is not enabled in Cargo for versions that are supposed to be API-compatible (minor version differences).

By contrast, if you were to use ureq == 3.x in energy_reader, this compile error would go away on its own, even with questdb-rs == 4.0.3: You would detect both versions of ureq compiled side-by-side when doing a cargo tree.

Resolution

We will keep having to pin our version of ureq until we can trust that ureq will respect semantic versioning, maybe it will with 3.x?

In the meantime we will periodically update the pinned version of ureq. We'll do it next time we have a round of updates on questdb-rs client.

PR?

If you have a more urgent need for features/fixes present in ureq==2.10, we would welcome a PR that upgrades the questdb code, otherwise you'll see this done as part of our regular maintenance over the course of the next few months.

P.S.: @algesten, is semantic versioning of ureq something we can rely on going forward from v 3.x onwards? Software versioning and dependency management is hard, and I know you've hard pragmatic objections to strictly adhering with semantic versioning of ureq in the past.

[amunra]

Random notes, I wonder if https://github.com/obi1kenobi/cargo-semver-checks and/or https://github.com/cargo-public-api/cargo-public-api would have helped.

[algesten]

@amunra

P.S.: @algesten, is semantic versioning of ureq something we can rely on going forward from v 3.x onwards?

It will certainly be much better than 2.x. As you identified in this issue, ureq 2.x re-exported rustls (among other) semver 0.x crates, meaning we had breaking changes in those re-exported APIs that we, rightly or wrongly, didn't accept as major version bumps in ureq.

For ureq 3.x this changes completely. We will only have one single re-export, the http crate which I consider being the ureq 3.x API. All TLS, cookie handling etc is now configured via our own wrapper APIs that we are committed to regardless of changes to rustls (and/or native-tls).

So in short. Yes. ureq 3.x will have better adherence to semver, for sure.

[amunra]

Ok, I'll take a look. Hopefully we can port over given we have the same auth logic with rustls for both tcp and http.

Thanks for responding, btw!

[jhaand]

Thank you for the updates. I will upgrade once this has been fixed.

[amunra]

From v5.0.0, we now use ureq 3.x.x which allows us to plug in our TLS logic in a lower-level way. These issues should be more stable, but unfortunately ureq still advertises these as unstable and not semantically version, so these issues might reappear. We'll fix up our code if/when they impact dependencies again.