Version hell at "simplelog"

help
1 
cargo build
    Updating crates.io index
    Updating git repository `https://github.com/BVE-Reborn/rend3.git`
error: failed to select a version for `termcolor`.
    ... required by package `simplelog v0.12.0`
    ... which satisfies dependency `simplelog = "^0.12"` of package `render-bench v0.5.0 (/home/john/projects/render-bench)`
versions that meet the requirements `1.1.*` are: 1.1.3, 1.1.2, 1.1.1, 1.1.0

all possible versions conflict with previously selected packages.

  previously selected package `termcolor v1.4.1`
    ... which satisfies dependency `termcolor = "^1.4.1"` of package `naga v0.19.0`
    ... which satisfies dependency `naga = "^0.19.0"` of package `rend3-routine v0.3.0 (https://github.com/BVE-Reborn/rend3.git?rev=c7c2d85#c7c2d859)`
    ... which satisfies git dependency `rend3-routine` of package `render-bench v0.5.0 (/home/john/projects/render-bench)`

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

These dependency problems are two and three levels down from my code, so I have limited control.
The trouble is that current simplelog is locked to an obsolete version of termcolor. Wgpu specifies a minimum version, which is fine.

Aargh.

2

I solved this problem for myself by disabling the termcolor feature of simplelog, which isn't essential for my purposes. In the long term, I need to pick a new logging library, because simplelog isn't being maintained (PRs merged but no release), and it also doesn't compose well for my needs (its log filter rules can't be used separately from its IO).

1 Like
3

This was fixed in the simplelog git repository: Adjust dependency to support termcolor 1.2 by danielparks · Pull Request #131 · Drakulix/simplelog.rs · GitHub

However, the fix has not been published to crates.io.

1 Like
4

(The general lesson here is that one should not publish a library with anything other than ^ style (default) dependency version requirements, except for particular carefully-considered special cases. "The later version has a bug" is not a sufficiently good reason, because the bug might be fixed in a later patch.)

5 Likes
5

The comment for simplelog there says it was fixed, but the actual code in trunk still has

termcolor = { version = "1.1", optional = true }

That fix (is that an un-merged pull request?) would only have advanced the version to 1.2, anyway.
The current version of termcolor is 1.4. Hence the problem.

6

Yes. This is especially important for low level crates used by many projects and for which multiple copies won't work, such as this one. I submitted an issue on "simplelog". They should just use version "1" of termcolor. Simplelog should not be dictating versions to other crates.

Can I even override this? I'm not pulling in termcolor or simplelog; they're pulled in by lower level crates.

7

Yes, patches are applied transitively:

It’s also worth noting that [patch] applies transitively. Let’s say you use my-library in a larger package, such as:

[package]
name = "my-binary"
version = "0.1.0"

[dependencies]
my-library = { git = 'https://example.com/git/my-library' }
uuid = "1.0"

[patch.crates-io]
uuid = { git = 'https://github.com/uuid-rs/uuid.git' }

Remember that [patch] is applicable transitively but can only be defined at the top level so we consumers of my-library have to repeat the [patch] section if necessary. Here, though, the new uuid crate applies to both our dependency on uuid and the my-library -> uuid dependency. The uuid crate will be resolved to one version for this entire crate graph, 1.0.1, and it’ll be pulled from the git repository.

1 Like
8

version = "1.1" (the post-PR code) accepts any version greater than or equal to 1.1 and less than 2.0, so the PR (if it were released) would let you use termcolor 1.4.

9

Was able to patch versions to make this work. Thanks.

10

Same problem again, but one level higher, in a workspace:

error: failed to select a version for `termcolor`.
    ... required by package `simplelog v0.12.1`
    ... which satisfies dependency `simplelog = "^0.12"` of package `libclient v0.1.0 (/home/john/projects/sl/SL-test-viewer/libclient)`
    ... which satisfies path dependency `libclient` (locked to 0.1.0) of package `sharpview v0.5.1 (/home/john/projects/sl/SL-test-viewer/sharpview)`
versions that meet the requirements `1.1.*` are: 1.1.3, 1.1.2, 1.1.1, 1.1.0

all possible versions conflict with previously selected packages.

  previously selected package `termcolor v1.4.1 (https://github.com/BurntSushi/termcolor.git#71f0921f)`
    ... which satisfies dependency `termcolor = "^1.4.1"` of package `naga v0.19.0`
    ... which satisfies dependency `naga = "^0.19.0"` of package `rend3-routine v0.3.0 (https://github.com/BVE-Reborn/rend3.git?rev=c7c2d85#c7c2d859)`
    ... which satisfies git dependency `rend3-routine` of package `sharpview v0.5.1 (/home/john/projects/sl/SL-test-viewer/sharpview)`

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

The problem now is that "libclient", my own package and part of this workspace, needs to have the "termcolor" version overridden.

Currrently, my patches at the workspace-level Cargo.toml file are:

[patch.crates-io]
rend3 = { version = "^0.3.0", git = 'https://github.com/BVE-Reborn/rend3.git', rev = "c7c2d85" }
rend3-egui = { version = "^0.3.0", git = 'https://github.com/BVE-Reborn/rend3.git', rev = "c7c2d85" }
rend3-framework = { version = "^0.3.0", git = 'https://github.com/BVE-Reborn/rend3.git', rev = "c7c2d85" }
rend3-routine = { version = "^0.3.0", git = 'https://github.com/BVE-Reborn/rend3.git', rev = "c7c2d85" }
egui = {git = "https://github.com/emilk/egui.git", branch="master"}
egui_plot = {git = "https://github.com/emilk/egui.git", branch="master"}
# Winit integration with egui (turn off the clipboard feature)
egui-winit = { git = "https://github.com/emilk/egui.git", branch="master" }
egui-wgpu = { git = "https://github.com/emilk/egui.git", branch="master" }
libui = { version = "^0.9.2", git = "https://github.com/John-Nagle/ui-mock.git", branch = "arc" }
termcolor = { git = 'https://github.com/BurntSushi/termcolor.git' }


[patch."https://github.com/John-Nagle/ui-mock.git"]
rend3 = { version = "^0.3.0", git = 'https://github.com/BVE-Reborn/rend3.git', rev = "c7c2d85" }
rend3-egui = { version = "^0.3.0", git = 'https://github.com/BVE-Reborn/rend3.git', rev = "c7c2d85" }
rend3-framework = { version = "^0.3.0", git = 'https://github.com/BVE-Reborn/rend3.git', rev = "c7c2d85" }
rend3-routine = { version = "^0.3.0", git = 'https://github.com/BVE-Reborn/rend3.git', rev = "c7c2d85" }
wgpu = "=0.19.0"

[patch.'https://github.com/BVE-Reborn/rend3.git']
termcolor = { git = 'https://github.com/BurntSushi/termcolor.git' }

So Cargo is complaining, reasonably enough, that I haven't patched "libclient", which is a member project of the workspace. But how do I do that? Is there Cargo.toml syntax for that?

I tried putting the termcolor patch line into [workspace.dependencies], but that did nothing.

11

Exactly what dependencies are you using that are pulling in simplelog? I have two things to say about them:

  • simplelog should only be used by applications, not by libraries. If the simplelog-users are crates that provide both libraries and binaries, then simplelog should be behind a feature specific to the CLI commands that you should be able to disable. If not, file a PR with the crates.

  • If simplelog is truly unmaintained, then maybe the crates that use it would be open to PRs switching away from it?

12

I managed to turn off the "termcolor" feature in all uses of "simplelog". Some examples were pulling it in.

1 Like
13

Simplelog has been fixed.

4 Likes
14

What’s the correct solution for this case, if you want to publish a working version of your library before your upstream dependency fixes the bug?

15

There is no good solution for that specific situation. Ideally, perhaps there could be some way to have Cargo issue a warning in that case. But notice that such a bug doesn't stop users of your library entirely; they can cargo update --precise a downgrade, if there is indeed a relevant downgrade to be had. And if your library is already published and in use, then your existing dependents' lockfiles keep their code working.

So, to be in that situation as a library author, you have to be publishing either a new library or a version with a new dependency, and your dependency has to have a bug that you noticed, that is related to your own library's needs, and that you couldn't arrange to be fixed in the time between detection and your release.

If you find yourself in that situation, maybe you shouldn't rush out a release. Or maybe you should find a dependency that's better-maintained. Either is friendlier than breaking people's builds with an upper bound version requirement.

3 Likes
16

This topic was automatically closed 90 days after the last reply. We invite you to open a new topic if you have further questions or comments.