$ cargo culture
Should have a well-formed Cargo.toml file readable by `cargo metadata` ... ok
Should have a CONTRIBUTING file in the project directory. ... ok
Should have a LICENSE file in the project directory. ... ok
Should have a README.md file in the project directory. ... ok
Should have a rustfmt.toml file in the project directory. ... ok
Should have a file suggesting the use of a continuous integration system. ... ok
Should `cargo clean` and `cargo build` without any warnings or errors. ... ok
Should have multiple tests which pass. ... ok
Should be making an effort to use property based tests. ... ok
Would you mind linking a prominent example?
Thanks for the pointer!
@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
