failed to select a version for stb_truetype

[kurtlawrence]

Description

Currently building off a forked master and receiving this error:

error: failed to select a version for `stb_truetype`.
    ... required by package `azul v0.1.0 (C:\azul\azul)`
    ... which is depended on by `papyrus v0.6.1 (C:\papyrus)`
versions that meet the requirements `= 0.2.2` are: 0.2.2

all possible versions conflict with previously selected packages.

  previously selected package `stb_truetype v0.2.5`
    ... which is depended on by `rusttype v0.7.3`
    ... which is depended on by `andrew v0.1.4`
    ... which is depended on by `smithay-client-toolkit v0.4.3`
    ... which is depended on by `winit v0.18.0`
    ... which is depended on by `glutin v0.19.0`
    ... which is depended on by `azul_glium v0.22.0`
    ... which is depended on by `azul v0.1.0 (C:\azul\azul)`
    ... which is depended on by `papyrus v0.6.1 (C:\papyrus)`

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

I think it was broken since this commit 8c1b54f30763fb4a6a9f5af091da64392182808c .

Version / OS

• azul version: 752be516036341a95a5db03c5a3620d560261f6b

• Operating system: Windows 10

• Windowing system (X11 or Wayland, Linux only):

Steps to Reproduce

cargo run using azul as dependency.

Expected Behavior

Actual Behavior

Additional Information

Tried with edition = 2015, edition = 2018 and no edition specified in cargo manifest.

[fschutt]

Yeah, it's because smithay-client-toolkit accidentally "upgraded" their dependency of stb_truetype 17 hours ago without bumping the major version. I don't blame them, they probably thought that it was version-compatible. I told rusttype devs about this but they "don't consider compiler upgrades to be semver-breaking", and cargo ignores azuls lock file - so yay, more dependency wrangling bullshit. Thanks for reporting though, I'll see if and how I can fix it.

[kurtlawrence]

No worries, I really am liking this framework!

[fschutt]

Yeah, I have mostly been arguing whether switching to a monorepo-style deployment would be a better idea. I can only "fix" this by either upgrading to Rust 2018 or forking every crate in the dependency chain to fix the dependency issue. This is not the first time this happened, same thing happened one month ago with dwrote. And it won't be the last time, because cargo likes to ignore the .lock file of this repo. It has to do with how cargo manages semver. At least for me it's a bigger issue, because I'd like to have a certain reliability, that my code builds, and I'm sick of fixing dependency issues every two days, switching to a monorepo style has certainly advantages for larger crates like this one, but also has huge tradeoffs, so we'll see.

[fschutt]

Closed in 5098ab3

[chris-morgan]

I am freshly looking into Azul, and this vendoring of dependencies seems like a bad idea to me, leading to more maintenance work rather than less (because you no longer have tool support), and a degree of fracturing from ecosystem-wide established conventions. It genuinely makes me uneasy about whether to use Azul or not (and I won’t be alone in this discomfiture). It also leads to code duplication if my code incidentally depends on some of the same things and manages its dependencies the normal way.

As far as I can tell, all you really want is to specify exact version numbers in Cargo.toml. That’s possible: just write foo = "= 0.1.2". Is that not a much better and simpler solution?

But I do agree with you that a sprawling dependency tree of pre-1.0 crates does cause trouble from time to time. Of course, nominally pre-1.0 everything is fair game.

[fschutt]

Well, of course it will lead to duplicated dependencies, but from my perspective, that's easier to manage than having code break every five days. This has nothing to do with pre-1.0 / post-1.0, this has everything to do with cargo ignoring Cargo.lock files on libraries. This is a structural problem of cargo which I can't fix.

because you no longer have tool support

What "tool support"? Building with cargo still works fine.

As far as I can tell, all you really want is to specify exact version numbers in Cargo.toml. That’s possible: just write foo = "= 0.1.2". Is that not a much better and simpler solution?

No, that is not possible, because if you have two crates like this foo = "=0.1.12" and foo = "0.1" somewhere in your dependencies, cargo will simply fail to build (instead of merging the two crates or compiling both or being a bit smarter about it). In fact, that is actually what causes this issue (I specified stb_truetype as = 0.2.2, and cargo failed to realize that it can merge =0.2.2 and ^0.2.4).

I know that it's not the "normal" way, but the "normal" way is currently extremely broken. If someone messes up semver and it breaks my code the next day five dependencies down the line and this happens over and over and over again, then that is a broken system and whether it causes discomfort or not - I quite frankly don't care. There is currently no better way, because cargo has severe structural issues here (which I reported back in March, got ignored by the cargo team).

[chris-morgan]

=0.2.2 and ^0.2.4 can’t be merged—one says “exactly 0.2.2” and the other says “at least 0.2.4”. Was there a typo there?

So long as you specify all of your dependencies as =, the problem should be averted, should it not? That makes it roughly a very slightly weaker lockfile.

[fschutt]

=0.2.2 and ^0.2.4 can’t be merged

Maybe (it was a bad example), but cargo should compile both, then. And it doesn't, it just gives you a "failed to select a version error" like this one and fails to compile. I don't know why that is the case, but it's just what cargo does.

So long as you specify all of your dependencies as =, the problem should be averted, should it not? That makes it roughly a very slightly weaker lockfile.

No - my example was bad, but you missed the point here: Let's say I put image = "=0.20.0" into azuls Cargo.toml. And you add azul to your Cargo.toml and then also add image = "0.20.1" in it. Then you can't build your code anymore: instead of compiling both versions, cargo will simply fail to compile. Don't ask me why that is.

Second, that doesn't solve the problem of sliding versions - now every direct dependency is specified with an = dependency, but every transitive dependency (i.e. dependencies of dependencies) are still specified as ^, and therefore are not "locked" to a version. You'd have to somehow go through every sub-dependency and put an = in their Cargo.toml, which is actually the job of the Cargo.lock file - but cargo ignores Cargo.lock files for libraries, that's the problem.

Also see #31 for the exact same error happening again. The third reason for this is that I can only fix versions of direct dependencies. It's easier to demonstrate this here:

                        stb_truetype ^0.2.5           <-- semver broke here
depended on by:         rusttype ^v0.7.3
depended on by:         andrew ^0.1.4
depended on by:         smithay-client-toolkit ^0.4.3
depended on by:         winit ^0.18.0
depended on by:         glutin ^0.19.0
depended on by:         glium ^0.22.0
depended on by:         azul ^0.1.0

How could I have "fixed" the semver problem of stb_truetype without forking every crate in the chain? The answer is, I can't. And at that point, why not fork everything, so that these errors don't happen again.
So that is why a seperate repo with vendored dependencies is the only choice that lets me even build my code again and not break every so often.