On the topic of the
.rustfmt configuration file, I'll refer to justification listed in the docs: https://docs.rs/cargo-culture-kit/0.1.0/cargo_culture_kit/struct.HasRustfmtFile.html#justification
On the slightly separate broader topic of getting to a rule set the community agrees with, I also agree* (with an additional nuance or two)
That said, it should handle both workspace-style and non-workspace-style Cargo.toml repositories
So, for example, I could run
cargo culture from the root of the https://github.com/PolySync/cargo-culture repo directory
or from the subdirectory containing the
cargo-culture-kit library subcrate
and the rules would be smart enough, when relevant, to make use of the
cargo metadata provided knowledge about the presence of a parent workspace
to sort out whether there might be, say, a LICENSE file up at the workspace root level rather than at the subcrate level
Does that answer your question, @Dylan-DPC , or did I misunderstand?
yeah it does
Just did a quick check, and it seems like the only one that behaves a little bit differently as a top-level rollup or an individual subcrate run is "Should have multiple tests which pass." , which will give you credit if you have
total_tests > 1 drawing from all your workspace crates in the roll-up scenario,
but naturally only gives credit if
total_tests > 1 drawing from the particular subcrate if you run in the context of just that subcrate
Which may be fine, or may be a point for refinement.
(I concur there's plenty of room to improve wording, just trying to understand which ways matter most)
That's what https://docs.rs/cargo-culture-kit/0.1.0/cargo_culture_kit/struct.PassesMultipleTests.html does, yep.
The current check does actually confirm whether or not the test build is failing.
ah okay
And for tests, you could integrate with coverage and use the % coverage.
e.g. actually running rustfmt to see if anything would have changed
e.g. using tarpaulin or coverage or mutagen or mull to examine test quality
I think the tough part of the cargo-culture project is striking the right balance between rules that are available versus those that are default
and having a great pattern for tailoring to organizational needs
@KodrAus But when compiler updates happen that result in new warnings for rustdoc … or a widely used crate gets an update … then having a list of things / crates would be useful.
@KodrAus Or things like right now, you can’t compile
serde docs with a nightly compiler.
I built the reorganize branch on mdbook 0.1.8 and verified it on http://www.yetanother.site/rust-cookbook/
:tada: