Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
    Zack Pierce
    @ZackPierce
    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)
    Dylan DPC
    @Dylan-DPC
    @ZackPierce also how does this work with subcrates?
    Zack Pierce
    @ZackPierce
    Currently the project is largely set up to be repository-oriented, as in, the happy path is to run it from the root of your Rust repository
    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?
    Dylan DPC
    @Dylan-DPC
    so you have to run over each subcrate manually?
    yeah it does
    Zack Pierce
    @ZackPierce
    I believe most of the checks "roll up" appropriately, so running from the workspace level should work equivalently to running from each subcrate manually.
    Dylan DPC
    @Dylan-DPC
    ah that's cool :)
    Zack Pierce
    @ZackPierce
    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.
    Dylan DPC
    @Dylan-DPC
    i feel "multiple tests which pass" could be misleading
    Zack Pierce
    @ZackPierce
    Could you elaborate a little bit on the problematic aspect?
    (I concur there's plenty of room to improve wording, just trying to understand which ways matter most)
    Dylan DPC
    @Dylan-DPC
    so you check if there is more than 1 test that passes?
    Zack Pierce
    @ZackPierce
    That's what https://docs.rs/cargo-culture-kit/0.1.0/cargo_culture_kit/struct.PassesMultipleTests.html does, yep.
    Dylan DPC
    @Dylan-DPC
    uhmm okay i got it now. you just want to check if the person has written tests, not whether the build is failing or quality of tests (which are of course difficult to gauge)
    Zack Pierce
    @ZackPierce
    Quality of tests would be a big project unto itself, one I'm okay with leaving out for now.
    The current check does actually confirm whether or not the test build is failing.
    Dylan DPC
    @Dylan-DPC
    yah i agree.
    ah okay
    Bruce Mitchener
    @waywardmonkeys
    @ZackPierce It might be nice to require certain compiler lints enabled.
    And for tests, you could integrate with coverage and use the % coverage.
    Zack Pierce
    @ZackPierce
    @waywardmonkeys Yep, I definitely see how it would be straightforward to do a number of integrations with extant tooling for deeper checks
    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
    Bruce Mitchener
    @waywardmonkeys
    @KodrAus I don’t think there needs to be a lotof coordination … but it would be helped by having better tools from crates.io for analyzing what things are using outdated versions … or which transitively depend on multiple versions of things.
    @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.
    Ashley Mannix
    @KodrAus
    @waywardmonkeys Yeh, I was wondering if something like a GitHub repository with issues, maybe containing a checklist of relevant libraries, might be visible enough for folks to get involved?
    Zack Pierce
    @ZackPierce
    @KodrAus thanks for submitting some issues on cargo-culture!
    Andrew Gauger
    @AndyGauge
    mdbook 0.1.8 shipped today. I am prepared to release the cookbook!
    I built the reorganize branch on mdbook 0.1.8 and verified it on http://www.yetanother.site/rust-cookbook/
    Ashley Mannix
    @KodrAus
    @AndyGauge That's great! :tada: Sorry I've dropped the ball over the last few months. Is there anything you need from @aturon or I to move forward?
    Andrew Gauger
    @AndyGauge
    aturon gave a review, and I did try to address them. I think we cut over and create new issues to address them. I think it is better to release and fix than try to make it perfect first.
    Ashley Mannix
    @KodrAus
    Let's do it :+1:
    Andrew Gauger
    @AndyGauge
    I did it about 20 minutes ago.
    :tada:
    Ashley Mannix
    @KodrAus
    :tada: :tada: :tada:
    Andrew Gauger
    @AndyGauge
    https://www.reddit.com/r/rust/comments/8xubdr/rust_cookbook_is_now_reorganized/
    Dylan DPC
    @Dylan-DPC
    @AndyGauge awesome work on the cookbook :ok_hand: gratz
    Andrew Gauger
    @AndyGauge
    I'm working on an RFC draft for proposing moving lazy_static! into std https://github.com/AndyGauge/rfcs/blob/lazy-static/text/0000-lazy-static.md
    I'm sure I've used some incorrect terms in the RFC and would love others to review it before I took the next step to submit it.