An example, merge conflict resolution, a rendering review and a rendering bug fix. Ahh, I'm so excited, even without the release notes fully done. This is my first release after starting full-time, and it really hits different when it's your job. Hundreds of merged PRs in only a few months!
@josh Yeah, deadlines are brutal in open source because of this problem. I've struggled with feeling like this in the past around releases (or for org process work) and it's so hard.
Straw-people love to say that #rustlang is terrible for quick-and-dirty scripting tasks: just write Python or Perl!
My experience with it has been great though: CLIs are so smooth to write, there's great crates for all the dumb little things you want to do, and path + string processing is super easy. And then you can actually read / modify the script in the future. We've been working on a generate-release script for @bevy with multiple contributors over the last month; it's been lovely.
Hardcode the set of options using an enum, use that in your methods everywhere and now it's typo-proof and trivial to extend. String interpolation for the HTML path using the Display trait just works too: no code changes needed :D
@dvshkn The trick is learning how to write quick-and-dirty Rust code. Enums everywhere, avoid lifetimes like the plague, just call .clone whenever the borrow checker complains and silence clippy lints aggressively :D Oh and use clap as the base for your CLI tools!
I wonder if there should be a lifetime-in-struct complexity lint for clippy 🤔
@faassen Good tooling is a huge part of why I like it for small projects. I don't need to think about how to manage dependencies: I just toss cargo at it and can be confident that it'll still work fine years from now, no matter what machine it's running on.
@weberc2@bevy Yeah, that makes a lot of sense :) In this case, the tool is run on developer machines only, so it's less of a factor, but for most other applications that's a massive factor.
Hi! It's time for this week's edition of the #bevymergetrain. If this is your first time here, every week a do a round up of the community-reviewed PRs for @bevy, the #opensource#rustlang engine for #gamedev that it's now my full-time job to help maintain!
There's a whopping 20 PRs ready this week; let's check in on and each of them and I'll make the final call:
Good error messages are everything! In this case, we can trivially improve an error message in our low-level pixel-by-pixel image construction API by telling users the right number of pixels to use.
More "what are the networking people doing over there" PRs. In this case, they've requested that some more methods on our SceneEntityMapper type be made public for use with both networking (maybe?) and for multi-world and advanced scene patterns.
Okay sure, I don't see any harm to doing so, the original author is on board and this is already really nicely documented. Merging.
Oh hey, it's my PR. This PR adds compass direction constants (e.g. north and south-west) to the 2D direction and rotation types.
It's since gotten valid critical feedback: it gets the S-Ready-for-Final-Review label removed and the S-Waiting-on-Author label added 😅 No bypassing the processes! If they're broken for the maintainers to follow, they're broken for other trusted contributors. In this case though, no big deal: I should definitely fix or respond.
Ah dependency trees. Since we've moved the app state code out into its own crate, we shouldn't be pulling a dependency on it via bevy_app: this should be a fully optional component.
That means that to keep the existing APIs we need to use an extension trait to get the old init_state method back on App: inherent impls are only allowed in the crate that defines a type. Needs a migration guide, but otherwise looks good. I'll write that, then merge.
Finally, we have a nice little code quality PR for our new substates feature.
Turns out, clippy and friends don't work on macros, so it's harder to ensure nice code there. Simple enough, and I like the changes. Tests still pass (and the state stuff has a number of them) so I'm comfortable that there's been no change in behavior.
@bevy That was fun :) We are in release-prep mode for Bevy 0.14, but I think it's important to keep the weekly merge train alive even as we do that. It's valuable for contributor morale, it gives me something to do beyond reviewing tricky PRs and writing the release notes, and it helps keep the small, uncontroversial improvements flowing.
Writing about it really does help me think more clearly, and I really like how it helps teach the very soft, often-ignored judgement / triage skills.