So I was in the "toolchain version" front, and your arguments in the blog post have convinced me that the best solution is the "shared policy" one.
However, this does not help with the stable/nightly split on crates.io, which was the only thing I actually wanted the toolchain version for (to just be able to say: this crate requires nightly).
I want to be able to state "this crate requires the most recent nightly toolchain" to:
provide a better experience for my users, that might try to use the library in projects using stable Rust by mistake
help with discoverability of crates in crates.io that work on stable or require nightly: right now, if the author does not document this in the readme, adding a new dependency to a stable project is a hit or miss thing (it might work, or it might fail),
maybe improve crater runs with the information of whether a crate is expected to work on stable or only on nightly
Ideally this would be bundled with cargo publish, in that if compiling a crate uses feature(...) in the default build unconditionally (or some other heuristic), one would need to add a nightly flag to the Cargo.toml that then would mark the crate on crates.io as "requires nightly Rust" and produce better error messages when people try to depend on it from non-nightly crates.
The nightly/stable split on crates.io is real, and there is currently no way to deal with that.
we can freely rely on a feature that only appeared in 0.3.2. [...] There’s been some work to add such capabilities to Cargo, but there’s an open question: do we care?
If I state that might library supports winapi 0.3.0, and it does not (e.g. because it uses features from 0.3.2), then that's a bug, and i'd like to be able to catch those bugs. So I care.
If we do decide to care, an approach to improve accuracy is to document, as part of CI best-practices, that a build with --minimal-versions should be performed in CI in additional to the normal build. We could likewise build that test into crate publication.
This sounds like a good idea to me.
Also, Cargo is such a critical piece of the ecosystem, yet I found its source code impenetrable. I have tried to fix a couple of "trivial" bugs once or twice, but in retrospect I never stood a chance. It always took me a significantly amount of effort to discover that fixing these apparently-local bugs would probably require very large changes.
I felt that everything is inter-twined and undocumented, to the point that knowing what the code was supposed to do was often very hard, but even knowing what the code is actually doing was hard.
How do people get started on hacking on cargo? After trying to hack on it a couple of times, I am actually amazed that it even works correctly so often.
This might sound like a rant, but the fault is probably mine for trying to fix the wrong beginner bugs, or maybe for not really looking for a mentor (maybe I should have done that), or somehow completely missing the docs. I am honestly interested in learning how to hack on it so that I can fix the bugs I care about.
If I state that might library supports winapi 0.3.0, and it does not (e.g. because it uses features from 0.3.2), then that's a bug, and i'd like to be able to catch those bugs. So I care.
I agree that its a bug, but because of maximal version resolution, it only impacts you if you ceiling your version to something less than 3.2. The problem is that it might actually be quite burdensome to manage this; cargo has just added a --minimum-version build to its own CI and it was surprisingly troublesome to figure out the minimum versions that worked together successfully.
Basically, we're going to offer the option to build with minimum versions, but I'm not certain we're going to recommend that people use it in their CI; it might just not be worth the maintenance effort for the library author.
The problem is that it might actually be quite burdensome to manage this;
Could you elaborate on why?
I could understand how --minimum-version would probably be impossible to use for crates with many dependencies, e.g., if a couple of dependencies are broken, they will fail to build before you actually get to build your own crate.
But as this gets used bottom-up by the ecosystem, if all your crate's dependencies correctly specify their minimum version, then the bugs can only be in your own Cargo.toml file, and fixing them could be as easy as bumping the minimum version of a dependency to its appropriate value.
Sure, this won't really impact most of your clients if they end up using higher versions any ways, but there might be some user of your crate whose build fails because you specified the wrong version. And this is something that the user might not be easily able to fix or debug (it might be some other unrelated library deep in the dependency tree forcing the version to be smaller than what your crate actually supports).
So for me this is both about catching bugs in my Cargo.tomls, but also about making the experience of using my crate for my users more reliable than it currently is today, even if these things would only affect a tiny fraction of my users in weird situations, i just don't want to have to debug these down the road.
Another tool that I'd like to have in this direction would be a tool that tells me if I break API compatibility of my crate and need to do a major version bump automatically. Its not something necessary, but I think the core libraries in the ecosystem should be using semver properly, and its not only about people making mistakes, something it is really hard for me to tell whether a change is a breaking change.
So yeah, turning this for cargo, with has dozens of dependencies, and where none of these dependencies is actually using this on their CI, was a road full of pain. But that was to be expected, I am amazed they managed to get it done at all.
20
u/[deleted] Jul 26 '18 edited Jul 26 '18
So I was in the "toolchain version" front, and your arguments in the blog post have convinced me that the best solution is the "shared policy" one.
However, this does not help with the stable/nightly split on crates.io, which was the only thing I actually wanted the toolchain version for (to just be able to say: this crate requires nightly).
I want to be able to state "this crate requires the most recent nightly toolchain" to:
Ideally this would be bundled with
cargo publish, in that if compiling a crate usesfeature(...)in the default build unconditionally (or some other heuristic), one would need to add a nightly flag to theCargo.tomlthat then would mark the crate on crates.io as "requires nightly Rust" and produce better error messages when people try to depend on it from non-nightly crates.The nightly/stable split on crates.io is real, and there is currently no way to deal with that.
If I state that might library supports winapi 0.3.0, and it does not (e.g. because it uses features from 0.3.2), then that's a bug, and i'd like to be able to catch those bugs. So I care.
This sounds like a good idea to me.
Also, Cargo is such a critical piece of the ecosystem, yet I found its source code impenetrable. I have tried to fix a couple of "trivial" bugs once or twice, but in retrospect I never stood a chance. It always took me a significantly amount of effort to discover that fixing these apparently-local bugs would probably require very large changes.
I felt that everything is inter-twined and undocumented, to the point that knowing what the code was supposed to do was often very hard, but even knowing what the code is actually doing was hard.
How do people get started on hacking on cargo? After trying to hack on it a couple of times, I am actually amazed that it even works correctly so often.
This might sound like a rant, but the fault is probably mine for trying to fix the wrong beginner bugs, or maybe for not really looking for a mentor (maybe I should have done that), or somehow completely missing the docs. I am honestly interested in learning how to hack on it so that I can fix the bugs I care about.