Add semver compatibility check

[DrRuhe]

By that I mean running cargo update -Zminimal-versions before running tests to ensure that there is no breakage when users use old (but according to semver valid) versions of dependecies.

I got the idea from: https://github.com/jonhoo/inferno/blob/main/.github/workflows/test.yml#L51

[ipetkov]

Definitely an interesting suggestion!

The hard part of supporting this is the fact that (IIRC) -Zminimal-versions requires cargo do to a fresh resolution. Vendoring crates in a sandbox friendly way is easy since all the information is captured in Cargo.lock, but resolving to different (i.e. minimal) versions would need access to every index of every registry that is used by the project. I'm also not sure how git deps play out here as well.

It may be possible to take an instance to the crate registries as an input to that derivation (though the caller will have to keep that updated) and trick convince cargo to use it instead of touching the network, but needs more investigation for sure

[dpc]

Would running cargo update -Zminimal-versions first, then capturing Cargo.lock then and following normal crane flow from there be an option / help with anything?

[ipetkov]

Would running cargo update -Zminimal-versions first, then capturing Cargo.lock then and following normal crane flow from there be an option / help with anything?

Yes I think that would work, but it would need to be done (either manually or via automation) outside of a nix invocation

[dpc]

Yes I think that would work, but it would need to be done (either manually or via automation) outside of a nix invocation

Why exactly? For caching reasons?

In Nix if you take source X that produces result RX, and then use RX to produce Y, if one alters X to be X', but after running it still produces exact RX, will Y need to be rebuilt? It would be great if it was possible to not get it rebuilt and get Nix to notice that inputs of Y are exactly the same. That's how layers in Docker work BTW and it's been very handy.

[ipetkov]

Why exactly? For caching reasons?

For network sandboxing reasons. By default cargo will fetch the crates.io index over the network and then use that for resolving which crate versions are to be used, but the nix sandbox blocks network access (unless you pass the --impure flag).

If we provide a checkout of the index within the sandbox (e.g. track the crates.io index as a flake input so its easy to update when it advances) it may be possible to make it work, except now the index is an input and changing the index could result in invalidating the builds. Maybe there is a way to side step the cache invalidation there (IIRC nix is supposed to start supporting content addressing at some point where things only get rebuilt if the build outputs change not just the inputs), but the implementation itself will not be as simple as just running cargo update -Zminimal-versions inside of the derivation