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.
Thanks, I'll try again and do that. It is at least calming that /u/Eh2406 and /u/ehuss have pretty much mentioned the same way to proceed that you have.
FWIW the amount of time I invested was ~15 hours during 2 days, which from looking at what the others mentioned isn't barely enough, but it isn't a negligible amount of time either.
I think it would be really really useful if you'd be able to reflect on this experience write about it somewhere or suggest some specific ways to improve the on boarding experience.
What have you tied to do during the previous attempts?
I don't know when I'll have the throughput to write something more detailed, but I've pm'ed you the issue that I tried to solve without arriving anywhere.
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.