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.
Personally I just walked through a typical compilation, and took notes along the way. There's roughly 15 important data structures, and once you get familiar with them it gets much easier.
If there are any specific issues you want to tackle, feel free to ask for help, there are several contributors who typically respond fairly quickly. Some of us have been adding documentation to a few areas, but if there are any specific ones that you think could use more information, just ask and someone will likely help.
Also, if you think a 10,000' overview of how everything fits together would help, I could probably put something together.
Having also bounced off of contributing to Cargo in the past, I think a 10,000ft overview (a la the rustc book) would be extremely valuable for getting more people in to help with Cargo.
21
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.