Is there a version that (still) compiles with nightly-2016-07-07 ?

[azerupi]

I'm trying to build a webapp with Serde and Diesel, both using nightly for codegen. But diesel does only support nightly-2016-07-07 and I can't seem to build Serde for that nightly.

In my Cargo.toml I have:

serde = "=0.7.14"
serde_json = "0.7.4"
serde_macros = "=0.7.14"

I have tried 0.8.0, 0.7.15, 0.7.14, 0.7.13 and 0.7.12 but quasi always fails to build.

I've tried to find the cause of this and I have come up with a plausible hypothesis:

Even though I strictly rely on serde_macros = "=0.7.14" it itself relies on any serde_codegen = "0.7.x" so it downloads the latest compatible version, which is 0.7.15. That in turns relies on the latest version of quasi which I guess uses compiler APIs that are not yet available in nightly-2016-07-07

Is this possible? And what can we do about it?

[oli-obk]

I think there's a way to override the dependency: http://doc.crates.io/specifying-dependencies.html#overriding-dependencies

[azerupi]

That didn't work unfortunately 😢 [replace] can't be used without forking and cheating because, quoting the docs:

Note that when a crate is overridden the copy it's overridden with must have both the same name and version, but it can come from a different source (e.g. git or a local path).

One way I know of to specify a good version for serde_codegen is to manually modify the lock file, but that is a terrible idea...

I think it would be useful to be able to restrain dependency constraints even further in cargo. Something like:

[dependencies]
serde = "=0.7.14"
serde_json = "0.7.4"
serde_macros = "=0.7.14"

[serde_macros.dependencies]
# serde_macros depends on "0.7.x" constrain it to "<=0.7.14"
serde_codegen = "<=0.7.14"

But for now, I think it's an interesting flaw in the Serde ecosystem that old builds that built with a specific version of the compiler can end up not building anymore with that same version a couple of weeks later.

[dtolnay]

Yeah this is not supported well. Let us know if you have ideas how we could make this better.

For now you should be able to use this other way of overriding dependencies. I just did this successfully today for running benchmarks against 0.7.0 so even older than yours.

Basically clone the relevant dependencies (probably just serde) and create a .cargo/config file containing:

paths = [
    "/path/to/serde/serde",
    "/path/to/serde/serde_codegen",
    "/path/to/serde/serde_codegen_internals",
    "/path/to/serde/serde_macros"
]

Then rustup override set nightly-2016-MM-DD and you should be able to compile.

[azerupi]

The problem I have with that solution is that it's not very portable, unless I vendor serde. But I am not sure that there is a better way to do it at this point in time.

Let us know if you have ideas how we could make this better

I think the fundamental problem is that a minor version bump (e.g. 0.7.x in serde_codegen) allows to bump a major version of a crate depending on compiler APIs (e.g. 0.y.x in quasi).

So even though the API of serde_codegen does not change and so no major version bump is required, the targeted nightly does which can cause breakage even though semver has been respected.

Maybe this breakage can be attenuated by tightening the constraints on such sensitive crates, or bump the major version more easily when the targeted nightly (range) is changed.

[dtolnay]

Would this be fixed by serde_macros using an = dependency on serde_codegen going forward? That would stop an old serde_macros from pulling in a new serde_codegen. See #472.

[azerupi]

I think so, but I haven't thought it through, so don't take my word for it 😉

[dtolnay]

Nothing we can do about the past releases, but this should be resolved going forward by #472. Thanks for reporting this.

[azerupi]

Thanks for the fix!