@ZackPierce I had a quick poke through and this looks like a great tool to me! It looks like you've got both users (possibly newer ones?) in mind in the community by pitching
cargo-culture as an educational tool, like clippy tends to be. But you're also looking at organisations that want to maintain some consistent meta-style across their projects. I had a few thoughts on things you might be interested in supporting. Would you like me to log a few issues on the repo?
I'm also usually on gitter so if there's something you expect to have a relatively rapid back-and-forth discussion on, that works just fine as well.
On the other hand, it might be worth iterating on the rule set into something that the widest portion of the community agrees with. For example, should every repository have a rustfmt configuration file?
Another useful rule would be that the repository has a coherent .gitignore file (so that it ignores all "target/" folders), although this one is usually already ensured by
cargo init.
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.
