bevy_cli

[twilit dew]

Just stuff like "Aaah it’s no longer working with the newest Bevy / newest Rust" would be nice to have fixed

[pale viper]

Totally, though I believe the CLI is mostly agnostic of the version

[rocky oxide]

Yep!

[pale viper]

Is it mainly the web bundling + testing stuff you find the most valuable?

[twilit dew]

Great

[twilit dew]

Personally, in this order:

• bevy run web
• bevy new
• bevy lint

[pale viper]

I'm mostly in agreement, although I do think our support for bevy new is somewhat lacking

[twilit dew]

The linter is low because it almost never failed on CI for me, but that’s probably on me because I should enable the nursery lints (I like them and am fine with the limitations)

[twilit dew]

Yeah honestly, it’s just nice to have the implicit TheBevyFlock prefix haha

[molten merlin]

I use bevy new with the minimal template daily, but could easily just grab the cargo generate template if it wasn't upstreamed immediately

[pale viper]

Yup, makes sense given how few lints we have (and even fewer that are enabled!)

[rocky oxide]

also because you know how to write Bevy :p

[twilit dew]

Same for me, just with a 50-50 blend of the 2D template and the minimal one

[twilit dew]

Yeah totally. I'm not the target audience for some of these 🙂

[rocky oxide]

Spiders Georg who makes a new Bevy project daily is an outlier and should not be counted

See, bevy new is basically worthless to me, because I make a new Bevy project like... once every 6 months?

Useful for onboarding, and useful for the editor though!

[pale viper]

That's more than I do! >:D

[twilit dew]

For me it’s like 2 weeks since I started publishing more micro crates, also I often need new projects to create minimal reproductions for all the issues I like to create

[rocky oxide]

I have an eternal bevy-sandbox project for most minimal repros 🙂

The really bad ones get spun out though, to be fair

[twilit dew]

Makes sense, I should probably also have one of those haha

[molten merlin]

🤔 global target and your whole system is a sandbox! 😆

[twilit dew]

bevy new bevy to get people started on contributing to Bevy

[molten merlin]

its very nice to have bevy new be the start of workshops and such

and crate instructions, etc

[rocky oxide]

Ooh, bevy new bevy/examples/alien_cake_addict

or bevy new leafwing_input_manager/examples/simple

Being able to use examples as templates is actually a pretty slick idea

[twilit dew]

@pale viper oh I forgot, add to the top the ability to change features for dev and release via metadata

[pale viper]

Ahhhhh, yes, especially for dynamic linking and the dev tools

[pale viper]

If it isn't supported, we should just upstream this to cargo-generate

[molten merlin]

subfolders are supported

[pale viper]

We've been benefiting so much from their work, I'd love to give something back

[twilit dew]

Yep. I have a neat little matrix of "this for web, this for web dev, this for native release" etc, which would be extremely annoying to use without the CLI

[rocky oxide]

Yeah, I think this is a good cargo-generate feature in general if they want it

[twilit dew]

NB this is how e.g. ratatui do things. They have one template repo with subfolders for each individual template 🙂

[molten merlin]

one of the downsides of whitelabelling cargo-generate the way bevy new does is passing the options has to be enabled specifically (for ex: subfolders afaik)

[pale viper]

https://cargo-generate.github.io/cargo-generate/usage/index.html#templates-in-subfolders

[rocky oxide]

I do like white-labelling it though

(being sure to credit generously)

It creates a much clearer new user experience

And allows us to seamlessly swap backends as needed

[pale viper]

Yeah... we need to do more of this (https://github.com/TheBevyFlock/bevy_cli/issues/479)

[molten merlin]

yes from the bevy new instead of cargo generate perspective, but not from the "we have to safelist all of the features in" functionality

I guess I don't know if the intent is to remove it and reimplement in the long-term though. that's what most projects end up doing for this kind of functionality, for better or worse

[pale viper]

I'd like to steer away from reimplementing it, from a maintenance perspective

cargo-generate provides a nice experience to both template users and authors already

[rocky oxide]

Yeah, if we can

It's just nice to have the option

[limber wedge]

im not sure how the upstreaming process worked for the other crates but something that's important to me is that all contributors (not necessarily all individual contributions) are also "upstreamed" ^^ We had many one time contributors who might not actively contribute to the new repository, but i think they should still be acknowledged there.

[pale viper]

I'm ranking various issues on their impact, and this is my scale lol

My personal favorites are "Forest" and "Big Forest"

From the list, there's still a few high-impact low-difficulty things we can do, which is exciting :D

[rocky oxide]

Here's a good lint for y'all: spawning a component of type ()

Or inserting / removing it

[twilit dew]

goes and allows it for my macros

jk, that sounds like a sensible lint

e.g. in spawn(tranform.look_at(...))

instead of spawn(transform.looking_at(...))

though I suppose in specifically that case there is already a should_use in place

[twilit dew]

this is really cute 😄

[rocky oxide]

Or when you have a &mut self method 😦

[twilit dew]

look_at is &mut self 😄

[pale viper]

Bam! https://thebevyflock.github.io/bevy_cli/api/bevy_lint/lints/suspicious/insert_unit_bundle/index.html

Beat you to it :)

[twilit dew]

Woah!

[rocky oxide]

!!

[rocky oxide]

Does this also work on insert too?

[pale viper]

Nope, but it should! Let me file an issue

[foggy basin]

Is it now possible to add issues from other organizations to your personal project? I think I couldn't get that to work in the past

[foggy basin]

I'm so happy that we can finally use let chains!

[pale viper]

Yup, although I discovered it by accident! If you paste the link to the PR or issue into the project, it will automatically be added. The link can be from any repo

[pale viper]

Ok, https://github.com/TheBevyFlock/bevy_cli/pull/456 is ready for review! We're actually two Rust releases behind, so #456 is only part 1

I made the PR as easy to review as possible, so please give it a look if anyone has the time :)

[limber wedge]

Will check tomorrow!

[pale viper]

Thank you!!

[foggy basin]

Refactoring PR that I wanted to do for a while already:
https://github.com/TheBevyFlock/bevy_cli/pull/498
It puts all the available commands in a commands module to make it easier to find things

[pale viper]

There will be a PR tomorrow, insert_unit_bundle is getting a makeover! 💅

[limber wedge]

Thats so cool! I had it setup for nvim aswell a few months ago but then sadly i no longer have the clippy diagnostics (since i use clippy as an override command)

[twilit dew]

How do I use the Bevy Linter in a project that uses the newest stable Rust?

If I install the linter with nightly-2025-04-03 it will yell at me because let-chains are unstable, from its point of view

But from the POV of the current stable rust, they are stabilized

I just tried migrating Chainboom to the newest stable version and am hitting a roadblock there

Also, minor annoyance on the SEO here:

The first link is irrelevant, and the second link is a 404: https://thebevyflock.github.io/linter/index.html. Could we maybe redirect it to https://thebevyflock.github.io/bevy_cli/linter/index.html?

Hmm, I suppose I should try 0.4.0-dev

But it seems this is invalid for the workflow? uses: TheBevyFlock/bevy_cli/[email protected]

Hmmm when using the bevy_cli from main and typing bevy lint --yes, it uses the outdated bevy_lint that was already installed on the system before upgrading my CLI to main

Uninstalling bevy_lint 0.3 and then runnign bevy lint --yes with the newest main gives me this 👀

[limber wedge]

The cli only supports installing the latest release of the linter yet sadly

You could try the action.yaml from main. There we updated to nightly-2025-05-14

[twilit dew]

I'll try with cargo install --git https://github.com/TheBevyFlock/bevy_cli --branch main --locked bevy_lint

Oh hey I can also point it to rev 9a24ac4a555f028f9d32017e95fcd1efcee1d3d3

Which is the commit that uses the newer toolchain

cc @near mist this is also relevant for the 2D template

This is what I landed on: https://github.com/Bevy-Jam-6/chainboom/pull/84/files#diff-944291df2c9c06359d37cc8833d182d705c9e8c3108e7cfe132d61a06e9133dd

[pale viper]

Unfortunately you need to wait for another release of the linter

You can install from main, but I haven’t fully upgraded the linter to the latest tool chain yet

[limber wedge]

I thought so too at first but dont we use 1.89 nightly?

[pale viper]

So let chains are still unstable, from the linter’s perspective

[pale viper]

Yes, but you’d need #![feature(let_chains)]

Actually that should work

[twilit dew]

Why? It's stable, the feature should not be needed

[pale viper]

@twilit dew #![cfg_attr(bevy_lint, feature(let_chains))] should fix it

[pale viper]

Let me test it, I don’t know for certain

I take it back, let chains work off of bevy_lint's main branch! Sorry about that ^^'

v0.3.0 won't work, but v0.4.0-dev will

But looks like you already figured that out. Sorry for the confusion!

[twilit dew]

All good, CI is green now, that's all I wanted 🙂
https://github.com/Bevy-Jam-6/chainboom/pull/84

Still, this is a big awkward for people using the 2D template from the CLI now

As they are almost guaranteed to get a broken CI

@pale viper what should we do about it? I can think of the following

• Remove bevy_lint from the 2D template for now
• Install bevy_lint from main with the rev 9a24ac4a555f028f9d32017e95fcd1efcee1d3d3
• Do nothing and wait for a new bevy_lint release

[pale viper]

I can backport the toolchain upgrade to v0.3.1 as well

I think I also should make the Github Action a little more usable, it's very brittle right now

[pale viper]

It was supposed to redirect, but it was broken. 😅 Here's a PR with a quick fix for it: https://github.com/TheBevyFlock/bevy_cli/pull/500

[limber wedge]

is there an easy way to test if this works when published or do you always just check if it works locally and then see afterwards ^^?

[pale viper]

I tested the fixed redirects locally before opening the PR, but the easiest way to see if it works in Github Pages is to publish it to Github Pages

Going to https://thebevyflock.github.io/bevy_cli/bevy_lint/ now correctly redirects you, so things are fixed!

[pale viper]

I opened https://github.com/TheBevyFlock/bevy_cli/pull/501, which makes installing the linter from a specific commit work with the custom Github Action. You'll be able to write:

- name: Install `bevy_lint`
  uses: TheBevyFlock/bevy_cli/bevy_lint@9a24ac4a555f028f9d32017e95fcd1efcee1d3d3

Instead of cargo install-ing it yourself!

[twilit dew]

Perfect, that should be good enough for the 2D template 🙂 Can you ping me when it's available?

[pale viper]

Yup, I’ll let you know when it’s merged!

[near mist]

this is to use a more recent version of the linter to access new lints?

[twilit dew]

No, it’s because the less recent linter uses an older rust toolchain, which does not accept let chains yet

[twilit dew]

But clippy will yell at you now if you don't use let chains, as they were recently stabilized

[pale viper]

The lint improvements I was showcasing in this video are open in a PR: https://github.com/TheBevyFlock/bevy_cli/pull/502

I really outdid myself with the PR description, although the diff for the lint itself isn't great

[limber wedge]

Not sure if i get to it before Sunday. Last exams are on Saturday and i still should study a bit but after that i have lots of time!

[rocky oxide]

Good luck!

[pale viper]

No worries! The PRs can wait, your studying can't :)

[limber wedge]

Thank youu!

[whole iris]

The cli is so nice to run on web, I hated fiddling with trunk

[pale viper]

@limber wedge do you want me to fix the CI errors and merge conflicts in https://github.com/TheBevyFlock/bevy_cli/pull/463 ? I have a bit of free time, and would love to get it merged :)

[limber wedge]

Yes please! I am free now!!! will review all your prs tomorrow

[pale viper]

@foggy basin would you mind taking a look at https://github.com/TheBevyFlock/bevy_cli/pull/501 ? It makes the linter Github Action much more flexible, and will let me begin adding the linter to the engine's CI

You're the only other local CI wizard I know that isn't Francois :)

[foggy basin]

Done!

[pale viper]

Thank you so much! I’ll address your feedback later today

[pale viper]

I think we're getting pretty close to the next release of bevy_lint! The milestone of completed things is shaping up quite nice!

Are there any features / fixes we should try to get in before preparing the v0.4.0 release? Anything that's missing or less-than-desirable?

Take a look at the list of open linter issues for things that may block the release

Also, should we release with support for Bevy 0.16 or 0.17? We currently support 0.16, but the release candidates for 0.17 are going to start at the end of the month

We'll want to update to support 0.17 relatively quickly: it's just the question of whether we should support 0.16 for people who want the new linter features but haven't updated

@limber wedge, @foggy basin, and @rocky oxide if you find the time I'd like your thoughts on this! :D

[rocky oxide]

0.16 IMO 🙂

It's really nice to get the testing earlier on full code-bases

[rocky oxide]

I've taken a look over the issues: I don't think there's anything blocking a new release. Lots of cool new lint ideas, and some really nice features like multiple version support, but no critical bugs or regressions

bevy lint --fix in particular is a really nice accomplishment

[foggy basin]

I would also say 0.16. As we don't have a fixed release schedule, we can just release again once 0.17 is out :)

[foggy basin]

On the latest main, I'm getting this weird issue:

$ cargo check
error: the 'cargo' binary, normally provided by the 'cargo' component, is not applicable to the 'nightly-2025-06-26-x86_64-unknown-linux-gnu' toolchain

I already tried rustup update and manually installing the toolchain.
Does anyone else get this?

Nevermind, looks like uninstalling the toolchain and installing again fixes it :)

[foggy basin]

Alright, I have a first working version of the experimental multi-threading support:
https://github.com/TheBevyFlock/bevy_cli/pull/499
We now need to find Bevy apps that have implemented Wasm multi-threading (it's not supported natively yet) to test it properly.

[foggy basin]

@pale viper @limber wedge we also need to discuss how to name experimental / unstable features in general and how they should be enabled.
Currently in the PR I named the feature "experimental" and the flags --experimental-multi-threading so the user always sees the "experimental" part and is not confused if it doesn't work.

@pale viper suggested to align more closely with cargo/Rust and name it "unstable" and using the -Z multi-threading syntax that's familiar from cargo.
With the -Z part I am a bit worried that we might create confusion with the Cargo flags itself as we also support them.
But I'm not opposed to change the syntax/naming :)

(The reason why I want the multi-threading to be marked experimental/unstable is that it requires nightly Rust and that it doesn't make the app multi-threaded by itself, you still need to manually implement the multi threading at this point)

[limber wedge]

Yea it should 100% be experimental. I think if possible we should always provide complete experiences if we call it a „stable“ feature.

Im pretty open about the syntax. I think i like having „unstable“ in the argument name the least. I rather have something like -Z (or out own flag) for experimental features. But since we already try to follow cargo i think reusing -Z makes sense (as long as its behind a subcommand of ours so its clear that its a bevy_cli flag)

[pale viper]

Yup, that's my sentiment as well! Do we support any of Cargo's -Z flags out-of-the-box? If not, that could reduce confusion

Ohhh right, we pass our flags directly to Cargo

[foggy basin]

Yea I think they can change relatively often so we don't really do any validation, we just pass them on

And I'm a bit hesitant to make the behavior dependent on the flag position (e.g. if its before or after the web), users already sometimes pass e.g. --release after web instead of before

[pale viper]

Yeah, positioning flags with bevy build web can be a bit tricky

We could eliminate it if we made a build-web subcommand, however

[foggy basin]

What would you think about using a different letter than Z? So keeping the syntax kinda similar but with still having a distinction?

[pale viper]

Would -U / --unstable work?

[foggy basin]

I do like the separation of the flags though, at least for the help output and code organization. But maybe we need to teach it better

[foggy basin]

Yea maybe, worth considering!

[foggy basin]

We'll also have to consider the config. How would unstable flags look there?

[tight shore]

I wanted to share this with everyone since we are talking about Bevy web builds
https://github.com/mate-h/bevy-webgpu

This uses Vite dev server to exchange the hot-module-reload files with the filesystem. so it's useful for during development of web builds. I implemented hot module reload for shader files in the web build this way.

[foggy basin]

Interesting approach!
Hot reloading is something I also want to support natively, probably via the Bevy Remote Protocol

The repo is a good reference, I didn't know about AssetServer::reload!
So far, my plan is to add a file watcher on the CLI side, forward the events via websocket to the app and then trigger the reload there

[pale viper]

Cross-posting this here: #general message

It's a poll to try to see how many people use Nix, and whether they'd like better support with the CLI / linter

Please fill it out if you get the chance! If we get a lot of responses asking for better support, we could possibly include Nix flakes in v0.4.0 of the linter

[gleaming plank]

I'm kinda an option 5: if native support for the Bevy CLI was added to Nix, I might start using Nix and encouraging my group to get it as well

[rocky oxide]

Do we have a .get_resource -> .unwrap lint yet? https://github.com/bevyengine/bevy/pull/20118/files#diff-f3b0002ebc5b04651ad671e722125208b6b7a522c873d0dcb4d6ae85d69409f7L33

[limber wedge]

In the panicking_methods lint we suggest using get_resource instead of resource and handle the error

[rocky oxide]

I think we should probably split that in two. Missing resource panics in production are really really hard to hit

[limber wedge]

But since you can return Result from systems whats the reason to use the silently panicking one instead of just using get_resource()?`?

[pale viper]

Yeah, shouldn’t it be the same to use get_resource()? instead of resource(), which gives you no ability to handle the error?

I’m open to changing the lint, I just don’t understand the reasoning yet!

Ah, wait, I see

In the code Alice linked, it’s running app.get_resource::<T>().unwrap(). We should recommend they use app.resource::<T>() instead

This is unrelated to panicking_methods, although it looks very similar!

[limber wedge]

Oh i just saw „world“ somewhere and thought its about that my bad

[pale viper]

You’re good! I was confused too!

[limber wedge]

i still dont see it: https://github.com/bevyengine/bevy/pull/20118/files#diff-f3b0002ebc5b04651ad671e722125208b6b7a522c873d0dcb4d6ae85d69409f7R31 isnt this: https://docs.rs/bevy/latest/bevy/prelude/struct.World.html#method.resource

[twilit dew]

Chainboom hit one due to a scheduling ambiguity that always happened to schedule stuff correctly everywhere except for some people in Wasm release builds
Discovered that one on day one into to the jam voting period.

[pale viper]

Yup, but it used to be world.get_resource::<PipelineCache>().unwrap(). Since that does the same thing as world.resource::<PipelineCache>(), the PR simplifies it

[limber wedge]

Imo the first one is better but i guess thats just a matter of taste

[pale viper]

I like the second one because of the custom panic message it gives you:

    pub fn resource<R: Resource>(&self) -> &R {
        match self.get_resource() {
            Some(x) => x,
            None => panic!(
                "Requested resource {} does not exist in the `World`.
                Did you forget to add it using `app.insert_resource` / `app.init_resource`?
                Resources are also implicitly added via `app.add_event`,
                and can be added by plugins.",
                DebugName::type_name::<R>()
            ),
        }
    }

[vast vine]

When you are hacking around it's annoying to have to change the function signature just for that

[limber wedge]

Yeye but you wouldn’t want a lint telling you to do the „hacky“ thing since while hacking you just ignore lints.

[vast vine]

kinda, I think what I would like is that lints like that are only enabled in a "release-ready" level lint or something like that. I think some lints are good even when hacking around because they highlight mistakes

[limber wedge]

Its always also important to keep in mind that lints are also helping new users learn

[rocky oxide]

A lot of users (especially for rendering) are going to be very annoyed by this lint if it causes problems with .resource(), and thus turn it off completely

Which is bad!

I personally prefer .get_resource() + ?

But when I tried to remove .resource upstream (to match the newly fallible .single), rendering was very "you'll pry it from my cold dead hands"

Because in many cases they don't have a reasonable recovery method, or adding one is a huge pain

[limber wedge]

I think we want to provide a method to configure some allow lints anyway and for this one it would make sense to be able to configure what methods are allowed without allowing the complete lint. Similar to: https://github.com/TheBevyFlock/bevy_cli/issues/399

[rocky oxide]

Yeah, I'm very okay with a configuration method instead of a split

[pale viper]

Makes sense! One good thing about panicking_methods is that it is opt-in, so you can enable it for the ECS, for example, while letting the rendering devs keep their world.resource()

[rocky oxide]

Do we have workspace lint overrides working BTW? 🙂

[pale viper]

Yup!

And crate-level overrides. Both are specified in Cargo.toml

[rocky oxide]

Excellent: clippy doesn't 🙃

Ideally we ban panicking_methods completely at the workspace level

[pale viper]

Yeah ^^'
I bypassed Cargo's normal method for setting workspace lints because I thought it was really annoying

[rocky oxide]

And then allow .resource inside the rendering crates

[pale viper]

@vast vine you'll like this. The panicking_methods lint won't step on your toes unless the crate you're working in opts-in to it :)

[vast vine]

We are actively moving towards using RenderStartup systems which means we'll use a lot less world.ressource()

[pale viper]

Right, I remember seeing those PRs. Cool!

[foggy basin]

@twilit dew at a later time I will also run an idea by you regarding better web GPU support.
I think we could probably support feature detection and dynamically loading either the webgl or webgpu version of the app depending on browser support for release builds :)
But would take a bit of implementation work

[twilit dew]

That would be hella cool 😄
But also, you should know that very soon™ all major browsers will have stable WebGPU

So for people targetting WebGPU exclusively (like me), it would be nice to just have an error message on WebGL

Which our current itch.io builds for example don't have. You just get a window that never loads.

[foggy basin]

That would be part of that change.
You could configure which APIs you support and if you only support webgpu it would show an error when the browser doesn't support it

I'm once again facing the problem of too many ideas, too little time!
There's still so many goodies we can put in the CLI...

[twilit dew]

Woah that would be great 😄

[pale viper]

Well I meant to send it here, but accidentally sent it in #1374187654425481266:

Should we release a small v0.1.0-alpha.2 that just includes the updated linter version number? Or should we get a better system setup for querying toolchain versions?

[limber wedge]

Im also okay if only main installs 0.4.0 but regardless we definitely need a better system.

[limber wedge]

I have been thinking a bit about bevy test web and I think it's easier to implement bevy check / bevy check web.

If we run cargo test --target --target wasm32-unknown-unknown, it compiles and tries to run the .wasm file and errors out.

There are a few methods on how to get cargo test working, but none seem optimal for us.

1. Use wasm-bindgen-test.
2. Write your own test harness (what wasm-bindgen-test does in the end).

The reason wasm-bindgen-test is not an option for us is that it requires you to annotate the tests you want to run with wasm_bindgen_test instead of test on top of other limitations. In my opinion, if we support a cargo test for the web, I would like to provide an experience where the user does not need to make any changes and can simply run all their tests for this target.

We could read the wasm binary and create our own test harness from that (like wasm-bindgen-test, but I think many built-in functions like assert! would not work in wasm32-unknown-unknown so it will not be a clean experience.

So I think it's easier to provide a bevy check web command that lets users test if their game still builds for the web in CI.

[twilit dew]

makes sense to me

Or bevy lint web

which would encompass check

[limber wedge]

Yea bevy lint web makes more sense

[rocky oxide]

Both Template and GetTemplate are blanket-implemented for any type that implements both Clone and Default. This means that most types are automatically usable as templates. Neat!
I smell a new lint...

From https://github.com/bevyengine/bevy/pull/20158

[rocky oxide]

I think that in the long-term we would want a lint for "all components (and maybe all resources) should implement Clone + Default XOR GetTemplate"

[lapis fjord]

Is it possible to do that in the type system? Like, checking if a type implements a A or B trait but not both?

[rocky oxide]

mutually exclusive traits aren't possible to express in Rust

And we don't want to do a Component: FromTemplate bound, because this is only "best practice", not mandatory

[foggy basin]

I updated the Wasm multi-threading PR to the new syntax:
-U web-multi-threading in the CLI or

[package.metadata.bevy_cli.unstable]
web-multi-threading = true

in Cargo.toml.
https://github.com/TheBevyFlock/bevy_cli/pull/499

What's left now is to add the changelog and documentation to the book :)

[foggy basin]

The PR is now ready to be reviewed :)

[twilit dew]

Potential lint?

fn on_add(trigger: On<Add, Foo>, query: Query<&Foo>) {
  let foo = query.get(trigger.target()).unwrap();
  // ... 
}

Looks innocent, right? This crashes with Disabled entities

Early return would also probably leave your entity in an invalid state once the Disabled is removed, since invariants from the observer are not held up

The correct thing is

fn on_add(trigger: On<Add, Foo>, query: Query<&Foo, Allow<Disabled>>) {
  let foo = query.get(trigger.target()).unwrap();
  // ... 
}

@slim pine am I getting this right?

Same on other hooks like Remove

[slim pine]

My specific case was an On<Add, Disabled> observer and then querying for trigger.target(), but the query failing because it is a disabled entity and I didn't explicitly include disabled entities in the query

[twilit dew]

Oh yeah that also sounds like a good case to lint

[slim pine]

But I think it would apply to your example too, yeah

[twilit dew]

Two potential lints then 👀

[slim pine]

I think it's just rarer to add or remove components from disabled entities so your case seems relatively rare

[twilit dew]

My case would get triggered by spawning something in a disabled state

(I think?)

[slim pine]

On<Add, Disabled> is common for anything that updates external indices or data structures that contain entities, like in my case updating the contact graph

[slim pine]

yeah true

[twilit dew]

let me check

Yep, this code here panics on 0.16:

use bevy::{ecs::entity_disabling::Disabled, prelude::*};

fn main() {
    App::new()
        .add_plugins(DefaultPlugins)
        .add_systems(Startup, setup)
        .add_observer(print_transform)
        .run();
}

fn setup(mut commands: Commands) {
    commands.spawn((Transform::default(), Disabled));
}

fn print_transform(trigger: Trigger<OnAdd, Transform>, transform: Query<&Transform>) {
    let transform = transform.get(trigger.target()).unwrap();
    println!("Transform: {:?}", transform);
}

@rocky oxide I assume this is not addressed by any observer overhaul, right?

[twilit dew]

For others reading this, to be explicit, this is the footgun:

fn print_transform(trigger: On<Add, Disabled>, anything: Query<&AnythingWhatsoever>) {
  let foo = anything.get(trigger.target());
  // foo will ALWAYS be `Err`!
}

Need to instead do

fn print_transform(trigger: On<Add, Disabled>, anything: Query<&AnythingWhatsoever, Allow<Disabled>>) {
  let foo = anything.get(trigger.target());
}

By just discovering this, I have realized that nearly none of my plugins properly deal with disabled entities 😅

CLI gang, should I open up two issues for these?

[foggy basin]

Sure, go ahead :)

[twilit dew]

Cross-post: #ecs-dev message

[twilit dew]

Done:

• https://github.com/TheBevyFlock/bevy_cli/issues/524
• https://github.com/TheBevyFlock/bevy_cli/issues/525

not sure how y'all do the labels nowadays, so I've just added C-Feature and A-Linter. Could you add others that would be good?

[foggy basin]

i believeThat works for now, thanks!

[limber wedge]

@shrewd monolith Tim linked your jam submission to test a PR and its so pretty and funky i love it!

[shrewd monolith]

We felt like we were so close to locking in on its potential. But uh, game jams are hard 😅

[limber wedge]

yea but the theme and the art + music is so good it really hits the vibe

[foggy basin]

Just doubled my laptop RAM to 32 GB so I can finally open the CLI and the testing workspace without risking crashing Linux 🎉

Next step will be upgrading my desktop PC as well (which is also still at 16 GB), but that one also needs a new CPU

[limber wedge]

Congrats!

[foggy basin]

I feel like 16 GB should be enough for just two projects with rust analzer, but who am I to judge :D

[limber wedge]

I dont think my pc could start RA

Yea but for some reason 16GB these days is not even enough for someone who only uses word (and teams) as a job

[foggy basin]

I remember when 16 GB was a lot... time flies by

[limber wedge]

True.. its a bit sad but maybe the electron hype goes away

[foggy basin]

I wonder if the recent optimizations to the reflect macro expansion also helps with rust analyzer memory for Bevy...
If so, it would be worth investing more effort into it probably

[foggy basin]

We just need BSN to land and we can rewrite all of those apps in Bevy

(Although I'm not sure how much memory Bevy apps are actually using... but surely less than Electron)

[limber wedge]

We will never know

But im glad that the MacBooks since apple silicon are so powerful it has never been an issue

And we have BYOD at work so its not as expensive

[foggy basin]

Ah, do they sponsor the hardware?

[limber wedge]

Yes!

[foggy basin]

Neat! At my job, the work machines are not for private use unfortunately

[limber wedge]

Well funny thing is i now work mostly for government contracts and there i got a different machine lol so i only use my BYOD device for private use lol

[foggy basin]

Good thing I can use Bevy as an excuse for "having" to upgrade my hardware for important "non profit work"

[limber wedge]

Hahaha truee!

[foggy basin]

Life hack!

[limber wedge]

Maybe i need to use that excuse to also upgrade my pc then it doesn’t not feel that bad

[foggy basin]

For sure, it's badly needed.
I think you require a 32 core CPU as well, with 256 GB of RAM. You never know how many Rust crates you have to compile in parallel

[limber wedge]

True truee! And maybe i also magically learn how to do rendering stuff so perhaps a better gpu would be good

[foggy basin]

I mean, for testing the CLI properly, you need to be able to run all the Bevy games, past and future. So a GPU would be a worthwile investment for sure!

[limber wedge]

Thats a good Argument!

[limber wedge]

its getting so much smarter 🍎

[pale viper]

Oooo exciting!!

[twilit dew]

Updated bevy_new_2d to a recent bevy_lint version to fix let chains: https://github.com/TheBevyFlock/bevy_new_2d/pull/445

[limber wedge]

https://github.com/TheBevyFlock/bevy_cli/issues/79 to get some inspiration

[slim pine]

cc @plush spade

[plush spade]

i think we can do some hacks using the cargo api to query the metadata for the main bevy crate even if you are just using bevy_* variants, i've done something similar before in another project

i guess in theory figuring out the target bevy version requires knowing at least one bevy crate that's present

but i feel like using heuristics (possible crate names x known valid bevy versions) we can make it work in 99.99% of cases

am going to cook a little 🍳

[pale viper]

I have a new PR up that halves the speed of the bevy_lint Github Action using caching! @foggy basin and @near mist you may find it interesting :)
https://github.com/TheBevyFlock/bevy_cli/pull/530

[near mist]

is this caching the final binary, or is it more complicated than that?

because if it was just a binary, i would have expected a bigger speedup

[pale viper]

It's caching just the final binary

The current slowest part is installing the toolchain every time, however I bet I could cache that as well!

Yup: ~20s to install the nightly toolchain, less than a second to restore the cached bevy_lint and bevy_lint_driver

[near mist]

ah ok, we have to install the rust toolchain in every job (except for rustfmt) anyways, and they run in parallel so that part is basically free

[pale viper]

Yup!

Another reason the speedup isn't more is probably because bevy_lint has very few dependencies (on purpose)

Compared to caching the entirety of the Bevy engine, the savings just aren't going to be as great

[near mist]

well ~47s -> under 1s is pretty big

looking only at the compilation of bevy_lint vs downloading it from cache

[pale viper]

Totally

[upbeat yew]

I am noticing an error in chrome with bevy_run_web
Content Security Policy of your site blocks the use of 'eval' in JavaScript

although this doesn't seem to prevent the app from working

[upbeat yew]

also, it would be nice to be able to listen on all addresses, but I cannot figure out a way to do it
looks like -host :: does work with both ipv6 and ipv4 addresses, and it was actually my nat to blame

[limber wedge]

yes exactly there is --host and --port

[limber wedge]

hm are the code snippets wrong? should they be rs fn on_add(trigger: Trigger<OnAdd, Foo>, query: Query<&Foo>) { // panics when spawning `(Foo, Disabled)` let foo = query.get(trigger.target()).unwrap(); // fails to uphold invariants of the observer when `Disabled` is removed let Ok(foo) = query.get(trigger.target()) else { return; }; } or is On<Add, Foo> something new?

[twilit dew]

It’s 0.17 syntax 🙂

Since we’re so close to the RC, I thought it would be best to use that

[limber wedge]

That explains 😄

[twilit dew]

Note that Allowed is also 0.17

Though it’s just an alias for Any<(With<T>, Without<T>)>

[limber wedge]

Yeye makes sense! Thanks

[pale viper]

Weird, we don't use the eval() function. If you make a new project with bevy new -t 2d, does it also give you that error?

I think that error occurs when you enable stricter browser settings, but I don't know of anything bevy run web would be doing that would be causing issues with it

[upbeat yew]

in _wbg_get_imports() in corn_game.js

    imports.wbg.__wbg_eval_e10dc02e9547f640 = function() { return handleError(function (arg0, arg1) {
        const ret = eval(getStringFromWasm0(arg0, arg1));
        return ret;
    }, arguments) };

[upbeat yew]

I think I need to set a CPS directive to get chrome to allow eval. but it doesn't seem to be working

[upbeat yew]

I have it set by the web server

still not working

well, the error turned out to be for an extension and not the bevy app.

that would have been nice information to have in the error

[vast vine]

Is it possible to use the bevy cli in a watch mode for the web option? I can't find any mentions of that in the docs but it would be very useful

Also, there's something wrong with the default css/html when the devtools are open. It tries to use a canvas the size of the full page and doesn't account for the devtools

[vast vine]

Oh, uh, looks like that was my fault. I was the one that set it to 1080p 😅

[near mist]

bevy run --verbose should help with this

[limber wedge]

Not yet sadly

[limber wedge]

Maybe over the weekend i will try to get an implementation up for this. At the moment im more leaning towards using: https://docs.rs/notify/latest/notify/ so we are more flexible than trying to integrate something like https://github.com/Canop/bacon.

[vast vine]

I tried wrapping my bevy run web command in bacon but it didn't work. Not sure what I did wrong, I feel like it should have worked.

[limber wedge]

i have never used bacon but i imagine this should work ```toml
default_job = "bevy"

[jobs.bevy]
command = ["bevy", "run", "web"]
need_stdout = true
background = true
on_change_strategy = "kill_then_restart"

[vast vine]

oh, I didn't try the background and on_change stuff

good idea

Would be nice if I could also pass in an example name separately but I don't think that's possible since web needs to come after

[limber wedge]

you can run bevy run --example ui_texture_atlas web or what do you mean?

[vast vine]

You can't do that with bacon is what I mean. You can't have a placeholder example_name in the command that gets replaced once you call the job

[limber wedge]

oh i see thats sad

[vast vine]

So I need to create a new job for each example

I mean, it's not too bad, I rarely work on more than 1 or 2 at the same time, but still, that's a bit annoying

[foggy basin]

Did you also try hotpatching with subsecond?
Or are there cases where that doesn't work but bacon does?

[vast vine]

Nope, but it's for wasm, would that even work?

But also, it's for work stuff and we are still on 0.15, so not sure if subsecond would work?

Anyway, in this case I want a full app restart for what I'm doing

I'm changing code that runs on startup

[foggy basin]

As far as I heard subsecond can also do wasm, but I haven't tried it myself yet

[foggy basin]

I see, thanks!
Trying to figure out if our eventual bevy watch should only be sub second or also has to support things like bacon :)

[vast vine]

I don't know about supporting bacon, but supporting a full reload should definitely be part of it

[limber wedge]

I think once im done setting up my new machine I would start preparing for the release of bevy_lint 0.4.0 @pale viper

I would also like a review for: https://github.com/TheBevyFlock/bevy_cli/pull/523 its mostly just boilerplate but it would make it easier to continue with: https://github.com/TheBevyFlock/bevy_cli/pull/529

[foggy basin]

Sorry I didn't have much time for open source recently.
Hopefully I can review PRs and finish the multi threading one soon!

[pale viper]

You read my mind! I've been enjoying summer, so I haven't spent much time working on open-source recently, but we definitely should try to release v0.4.0 before Bevy 0.17 is out. I had started working on the release branch a while back, so I picked it back up today and opened up https://github.com/TheBevyFlock/bevy_cli/pull/533 :D

<@&1064695155975803020> Hi! The Bevy Linter is ready to release v0.4.0, but per our release process we need at least one maintainer approval on https://github.com/TheBevyFlock/bevy_cli/pull/533 before we can move forward. I'd greatly appreciate it if you would test out the new features and make your last-minute change requests so that we can get this released before Bevy 0.17. Thanks!

If you're unfamiliar with our release process, definitely check out https://thebevyflock.github.io/bevy_cli/contribute/linter/how-to/release.html to see what steps are taken :)

[limber wedge]

A nice!! Will review it today! and totally with summer and holidays there are other things to do ^^

[twilit dew]

I believe this means we can close

• https://github.com/TheBevyFlock/bevy_cli/issues/49
• https://github.com/TheBevyFlock/bevy_cli/issues/311

[pale viper]

Looks like @rocky oxide merged https://github.com/TheBevyFlock/bevy_cli/pull/533, so the v0.4.0 release is underway! (Thanks for the reviews Alice and @limber wedge!) Give me an hour or so to create the Github release, as I'm not in a good position to do it right now :)

[rocky oxide]

You bet

[limber wedge]

Take your time!

[pale viper]

Could I get a quick approval and merge of https://github.com/TheBevyFlock/bevy_cli/pull/534 ?

I just realized I left this in

[limber wedge]

Wow alice is so fast

Was approved before GitHub mobile finished loading

[pale viper]

Merge train? More like bullet train 🚄 😆

[pale viper]

It's officially out! Woohoo 🎉

[shrewd monolith]

Hm, would it be possible to emit a warning if you pass an unstable flag that doesn't exist? I keep on forgetting the exact web-multi-threading flag, and only realize until after I've recompiled the whole project 💀

Currently, it both successfully completes and doesn't emit a warning, so it's impossible to know from the tool itself if the flag was valid! Maybe I should mention this on the mutli threading PR.

[pale viper]

Yup, we should definitely do that! Please leave a comment on the PR, so we don’t forget about it :)

[limber wedge]

Yes i think in the open PR thats one of the open points: https://github.com/TheBevyFlock/bevy_cli/pull/499#discussion_r2217341946 so you get auto completion and validation of your flags too

[foggy basin]

Yea I think I'll try to implement it with an enum instead :)

Sorry for the delay on the PR, I will still address all the feedback!

[foggy basin]

I'm curious, is there a certain variant you always use? If it's more intuitive, I might consider renaming the flag :D

[shrewd monolith]

well, I’ve done more than one 😅

1. multi-threading (thinking it’s contextual since it follows the web command)
2. web-multi-threaded

i think the current name is fine though

[foggy basin]

I think if we go with the contextual unstable flags like @limber wedge suggested, multi-threading will be the better choice. But I'm worried about having the same flag behave differently based on what you use it with.
The reason I choose multi-threading instead of multi-threaded is because the flag itself doesn't make anything multi threaded-- it just enables you to use it

[pale viper]

@limber wedge I made a few commits to https://github.com/TheBevyFlock/bevy_cli/pull/523 and fixed merge conflicts, so it should be merged in a few minutes! I hope you don't mind

[limber wedge]

Thats perfect! Now i can continue on the linter installation branch

[pale viper]

Awesome! I hope we can get that shipped out soon, because right now bevy lint --yes installs v0.3.0 instead of v0.4.0 :)

[limber wedge]

I would still also like a better way to share Clap argument types. Like we have quite a few duplicated types just for their doccomment and therefore the help message to change

[limber wedge]

Totally if you have time for a review once im done im sure we can still push it out this week.

[pale viper]

Definitely can do! Let me know when it’s ready

[twilit dew]

@shrewd monolith and CLI friends, what's the current way to get the experimental smooth audio in Wasm using bevy_seedling? I'm a bit out of the loop 🙂

[foggy basin]

First you'll need to install the CLI from this branch: https://github.com/TheBevyFlock/bevy_cli/pull/499
Then I believe there was either a feature in bevy seedling or a separate crate which enables the multi threaded audio (I'll have to check again)
And finally you have to run it with nightly rust and bevy run web -U web-multi-threading

I think you need https://github.com/CorvusPrudens/firewheel-web-audio in addition to bevy seedling

I'm not sure exactly how to plumb it together, but you might be able to find it in https://github.com/void-scape/chain-reaction, which is a game using the multi threaded audio

[foggy basin]

When you get it to work, please let me know!
I might add the process to the CLI docs on the feature, since that's the main use case so far
Also if you have any other feedback on the CLI integration I'm all ears :)

[twilit dew]

bevy setup bevy_seedling_with_smooth_wasm_audio_plz /j

I'll try when I hear from our friendly crow how to plumb it 🙂

Maybe setup a minimal repo so others can copy it if they want

[foggy basin]

I mean, we could totally do a repo and use bevy new :D

[twilit dew]

Oh right that's a good idea

And probably also add it to bevy_new_2d

[foggy basin]

I'm hoping to find some time this weekend to finish up the PR so we can merge it.
I'm super excited for the multi-threading stuff!

[twilit dew]

I think given that bevy_seedling upstreaming is nearly inevitable at this point, it would be alright to depend on it imo

[foggy basin]

We might need to guard it behind a cargo generate prompt though, since it requires nightly and not everyone wants to use it

[twilit dew]

Oh really? Didn't realize

Fair enough

[foggy basin]

Well bevy_seedling doesn't (AFAIK), but wasm multithreading does

[twilit dew]

Makes sense

[foggy basin]

Basically you need to activate some wasm features and also rebuild std with these features enabled.
That's currently nightly only, but according to François it might come to stable in the mid term

[twilit dew]

Ah that's great then!

Definitely something that is worth it for me, but I see how it shouldn't be the default yet 🙂

(I use nightly all the time anyways because of the compile time improvements)

[foggy basin]

Sorry it was Miles, not François

[foggy basin]

If we're lucky, seedling will also be upstreamed within that time frame, and then we'll really have a nice UX for all of this :D

I think the next year or two will be a huge leap for Bevy web apps

[shrewd monolith]

I should probably add an example for how to do it in bevy_seedling. The basic idea is that we're just swapping out the audio backend. bevy_seedling's main plugin is generic over the backend.

You'll probably want something like this in your app setup:

#[cfg(not(target_arch = "wasm32"))]
app.add_plugins(bevy_seedling::SeedlingPlugin::default());

// right now, `Default` isn't implemented for any non-cpal backend
#[cfg(target_arch = "wasm32")]
app.add_plugins(
    bevy_seedling::SeedlingPlugin::<firewheel_web_audio::WebAudioBackend> {
        config: Default::default(),
        stream_config: Default::default(),
        spawn_default_pool: true,
        pool_size: 4..=32,
    },
);

And then something like this for your toml:

[target.'cfg(target_arch = "wasm32")'.dependencies]
firewheel-web-audio = "0.1.0"

And, thanks to the CLI, it should be much easier to build and serve it :)

There's probably a more elegant way to do this. Although it seems like it would be kinda tricky to hide the details -- I like the plugin being generic over any backend.

[foggy basin]

One way could be to add a feature to bevy_seedling which would add the fire wheel web audio dependency and a plugin which just wraps the seedling plugin with the web audio back end.
You'd still have to do the target check, but it would be one dependency less to worry about. Not sure if that improves the UX enough to be worth it though :)

[shrewd monolith]

I do think something like this would be worth it. I'll make sure to include that in the next release

[foggy basin]

With the CLI you can also set up that some features are automatically activated when you build for the web, which would play nicely with this

[strong summit]

for some reason building clippy utils for bevy_lint is failing with 79 errors, and if i run bevy cli it complains about not having rustup. building from the main branch

[limber wedge]

Are you using the correct nightly version (nightly-2025-06-26)?

[strong summit]

im using a newer version which i assumed would be ok, should i try that one?

[limber wedge]

Yes you need to use the exact version specified in the rust-toolchain.toml

[strong summit]

ok

[limber wedge]

And are you on nixos?

[strong summit]

yeah

[limber wedge]

Then you are maybe also interested in this: https://github.com/TheBevyFlock/bevy_cli/pull/478#issuecomment-2965854010

[twilit dew]

@foggy basin

I assume by "add to the rustflags" you mean "replace the original rustflags", right? :/

Or do you have some nifty additive rustflags hack?

[twilit dew]

Context: if you pass rustflags to cargo build, it will silently only use those rustflags and ignore all flags you've setup in your config.toml or env vars

If my hunch is correct, is there a way to set the relevant headers in the web dev server and leave the rustflags to me?

[limber wedge]

Iirc this is still the case yea rustflags are a bit tricky

[twilit dew]

Update: oh, I see you don't pass rustflags over the CLI and just over the env var. That's great, but I would prefer there to be no env var at all since I use cargo.toml files full of custom configs 😬

[limber wedge]

I thought you couldn’t pass all rustflags over the cli?

[twilit dew]

Very possible

I don't know, I avoid it 😄

[twilit dew]

Maybe there could be a metadata field for headers in the Cargo.toml?

And maybe even for -Z build-std=std,panic_abort?

[limber wedge]

But ye we should definitely support your case

[twilit dew]

I suppose for now I could just fork that branch and disable the rustflags when using that option?

Oh, or hack in a --no-rustflags-env that just omits the RUSTFLAGS env var right before finishing 😄

Since any CLI command appending to that is a footgun for my setup

You know what? That's my feature request of the day ⭐

[limber wedge]

Its always hard to choose the right path between being flexible for powerusers / custom setups and easy out of the box experience for regulars

But we have to support config.toml somehow anyway in the long term.

[twilit dew]

https://github.com/TheBevyFlock/bevy_cli/issues/536

[twilit dew]

I think just allowing people like me to disable RUSTFLAGS and tell them "look, just make sure you have the right settings on your own" is fine atm

[shrewd monolith]

if you're just interesting in getting things running, you could also just follow the original recipe: #1236113088793677888 message

[twilit dew]

Thanks, but I will die before I build a Bevy app for web without the CLI again haha

[shrewd monolith]

(there are more target features and build steps than required in here though)

[twilit dew]

I believe I've got it running 🙂

[shrewd monolith]

it does recommend the CLI actually

[twilit dew]

Should have clicked on your link before answering lol

[shrewd monolith]

it just describes how you can run the web build with manually provided headers, which the CLI supports

[twilit dew]

Ooooh --headers="Cross-Origin-Opener-Policy:same-origin" --headers="Cross-Origin-Embedder-Policy:require-corp"

I didn't know about that 😄

great!

Thanks for the pointers!

[twilit dew]

And you even mention the option in the config.toml

this is perfect!!

Thanks a bunch 😄

[twilit dew]

oh my bad I already had an unstable table

@limber wedge do you know if this is still blocked?

https://github.com/TheBevyFlock/bevy_cli/pull/343

If not, I'll open another feature request for setting headers in the config

@shrewd monolith is there some easy way to test whether it's working?

Because it seems like it's working for me

But since it's a minimal app there's no stutter there anyways

[shrewd monolith]

if audio is playing (and you're sure it's actually using the firewheel web audio backend), then it's necessarily working

With the way it sets up the audio, it will only play audio if the whole thing's working

[twilit dew]

Ah, so there's no fallback to singlethreaded?

Great!

In that case, everything is working

[shrewd monolith]

I suppose we could do that

[twilit dew]

I don't even need that specific branch of the CLI thanks to you 🙂

shut

[shrewd monolith]

true

[twilit dew]

any way to silence that?

[shrewd monolith]

no idea 😅

it never triggers any of my ci so

[twilit dew]

it's from the +atomics

But eh, just a warning, I can live with that

I get like 3 useless warnings per minute from winit anyways

[shrewd monolith]

it also seems to trigger kinda randomly
i never know at what crate the atomics warning will pop up

[twilit dew]

Alright, now step 2: integrate this into Foxtrot 🙂

[limber wedge]

no this should be unblocked now

[foggy basin]

Maybe we need to take the bullet and manually implement the merging in the CLI 🙃

[foggy basin]

@twilit dew so your use case is you have a single .cargo/config.toml in the project that has a top level rustflags attribute?
That shouldn't be too hard to support, but the edge cases are painful

[twilit dew]

~/.cargo/config.toml on my machine, some_crate/.cargo/config.toml on CI 🙂

With different rustflags depending on the target

[foggy basin]

Do you want to create an issue for merging the rustflags from the config with the ones we need in the CLI? Ideally with examples on how you specify the rustflags in your toml?
I think I'd prefer implementing that over a flag to ignore rustflags, it feels less hacky and more user friendly

[twilit dew]

It's something that cargo has on the backburner for a while FYI

I don't expect to see it within the next decade given Cargo's iteration speed

but lots of people want this upstream

[twilit dew]

sure, also adding one for specifying headers in the config

[twilit dew]

https://github.com/TheBevyFlock/bevy_cli/issues/537

[foggy basin]

Thanks!

[twilit dew]

Next: https://github.com/TheBevyFlock/bevy_cli/issues/538

[foggy basin]

Hmm finding out the target might actually be non-trivial 🤔

(Well it is for web, but not for native)

[twilit dew]

That’s what I heard before 😬
IIRC dioxus also tried this, not sure if they succeeded

[limber wedge]

hm maybe we can read it out of the installed toolchain not sure how stable that is

like

❯ rustup show | grep "Default host:" | cut -d' ' -f3
x86_64-unknown-linux-gnu

[shrewd monolith]

i'm sure the nix folks wouldn't like this 😅

[limber wedge]

Haha thats true just an idea. In the end nix folks have to live with possibly pain points if they dont want to use a standard setups (it should still be usable!!)

[rocky oxide]

FYI

I've been thinking about this problem a bit more

And from the bevy_cli perspective, what would be ideally is if we could read the existing rustflags, append to them, and then restore them to their original state

I haven't worked with environment variables enough to know how hard that would be though

But this gets around the stupid problems with just overwriting any flags

[limber wedge]

did a quick prototype: https://github.com/TheBevyFlock/bevy_cli/pull/540 @twilit dew the idea would be merge the rustflags from the cargo config with the cli once, and if any are present always add them as env variables.

[twilit dew]

If this works, that would be fantastic 😄

I believe I linked my global config (~/.cargo/config.toml) in the issue

If it works with that, I'm more than happy!

[limber wedge]

i think it should will add tests later ^^

[limber wedge]

yes nice thanks!

[twilit dew]

seriously, this is soooo useful

Thanks for tackling it!

That also means no more footguns for getrandom bs

[foggy basin]

Awesome, thanks for working on this!

I've been thinking, what do you think about adding RUSTFLAGS not as env variable, but via the --cfg flag? (Not in this PR, would be a separate ticket)
I think I like keeping everything in a copy-pastable comment, and also makes the logs better IMO (I kinda dislike how we log the env variables right now)

[limber wedge]

yea totally! I think we should add a PR for this in https://github.com/taiki-e/cargo-config2 as this seems generally useful

[foggy basin]

I mean more for passing them to the cargo commands in the end, I'm not sure how we could include that in the crate :)

[limber wedge]

o yea i confused myself

[foggy basin]

So basically instead of the env we could inject something like

[build]
rustflags = [...]

into the config via --cfg.
It still wouldn't merge, we'd have to do that manually, but then it's part of the command invocation instead of env :)

[foggy basin]

I created a project board for bevy_cli web things, since it's a big part of the CLI and relates to many issues that need to be organized and prioritized
https://github.com/orgs/TheBevyFlock/projects/4
@pale viper @rocky oxide making it public requires more permissions than I have, what do you think? :)

[rocky oxide]

Yes this should be public 🙂

Ping me Sunday if you need help

[pale viper]

I can’t do this, but owners / admins of TheBevyFlock can, I believe! @trail shale could you please make the linked project public, when you have the chance?

[pale viper]

@limber wedge if you have the time, could you take a look at https://github.com/TheBevyFlock/bevy_cli/pull/517 ? It significantly improves the UX when the compiler ICEs on a specific span, although requires a bit of duplicated macro magic

It basically lets us run span_panic! and friends to include the piece of code that caused the panic

[twilit dew]

Did anyone ever look into improving the error: failed to obtain package metadata, are you in a cargo workspace? message?

I get that a lot when I heck up my Cargo.toml by e.g. pointing to a wrong dep and then have to use cargo check for better messages

I remember there was an issue about this

[limber wedge]

Yes! I will have a look in the evening

[limber wedge]

No i dont think so

[foggy basin]

Yeah we have an issue for it and actually I plan to look at it after the multi threading stuff. I also run into it quite frequently

[twilit dew]

Much appreciated 🙂

[foggy basin]

Alright, I reworked the multi threading PR according to the review feedback.
The unstable features are now specific to the web commands and implemented with an enum to get better help output directly from clap.
I also renamed the option to multi-threading since it's web-specific now (except in the config, it's still web-multi-threading there).
I also tried to simplify how the option is applied to make it easier to track what's necessary for the multi threading :)
https://github.com/TheBevyFlock/bevy_cli/pull/499

[twilit dew]

Great! Let me know when rustflag accumulation is implemented so I can use the multi-threading setting. Excited for this, that should make things much simpler!

[foggy basin]

It should work in combination with @limber wedge's PR :)
We'll let you know once both are merged

[foggy basin]

So you don't get bored while you wait, I have https://github.com/TheBevyFlock/bevy_cli/pull/543 for you :P

[twilit dew]

omg yesssssssss

[twilit dew]

Do you even need that String::from_utf8_lossy?

[twilit dew]

Thanks for looking into this 😄 Yet another use case for cargo over bevy has been eliminated

[foggy basin]

Hmm good question, maybe the bytes can be directly piped to the output...
I'll look into it :)

[foggy basin]

Seems to work, thanks!

[twilit dew]

Yay!!!

Much much much better 😄

Though the "are you in a cargo workspace" error is still misleading haha

Could we remove that error if there is already an stderr?

[foggy basin]

Yea true. Should we remove that?
Previously I thought that would be the most common error, but honestly not really

[twilit dew]

Yeah I think it didn't help once :/

[foggy basin]

Honestly doing it conditionally like that would be quite hard, I think :D

[twilit dew]

Hmm we could also just yeet it entirely

Presumably, this would be printed in that case, no?

[foggy basin]

Yea, right

Maybe I'll keep the "failed to obtain package metadata" since it might not be clear which command failed, but remove the "are you in a cargo workspace" part

[twilit dew]

that's a good idea 🙂

[twilit dew]

Maybe also add the info that that part is from the CLI

Right now nothing is differentiating it from the regular cargo output

[foggy basin]

Oh it's merged already, nevermind lol

[twilit dew]

bevy failed to obtain package metadata

[foggy basin]

That could suggest it's the bevy crate though, instead of the CLI

[twilit dew]

true

bevy_cli failed to obtain package metadata

[foggy basin]

I'm also reconsidering that the cargo metadata has tracing level for logging. I think it should just be debug like the rest, so you can easily see it with the --verbose flag

I'll create a follow-up PR :)

[foggy basin]

In the meantime, I have https://github.com/TheBevyFlock/bevy_cli/pull/544 for you :)

[foggy basin]

There you go:
https://github.com/TheBevyFlock/bevy_cli/pull/545

[twilit dew]

Someone's productive today 😄

[foggy basin]

Gotta use the open source time when I have it :D

So after the rustflag merging, what would be your next top requested CLI feature @twilit dew ? :)

[twilit dew]

Asset preprocessing, easily

I know we have API for that theoretically, but it's virtually useless IME

Like, it's certainly something nice to work upon in the future, but as a current user, it's not workable.

I remember Cart saying that it hurts a bit to see that nearly all 3D showcases of Bevy he sees have aliased textures in them, because there's no easy way to generate mips

And yeah, that kind of thing should be part of a preprocessing pipeline

So I have to setup things like this 150 line Python script: https://github.com/janhohenheim/foxtrot/blob/main/scripts/bake_assets.py

I don't expect any newcomer to be able to do this

[foggy basin]

How would you envision the asset preprocessing to work?
Would the hooks feature serve your needs, which could execute arbitrary commands before or after building?

[twilit dew]

also, take a look at our oldest issues in the CLI 😄

[twilit dew]

I can envision multiple variants

For my current asset baking, I convert all textures to KTX2, compress them, and generate mips for them. This process can take up to a minute

So that should not be running before every build haha

[foggy basin]

Fair enough lol

[twilit dew]

In this very specific case, having a command that I can run manually would be nice

So I can run it locally to test the baked assets, or run it as part of the release workflow

For a long time, we had basically no way at all to generate a cubemap for Bevy without a PhD, but mateh created his cool Blender script a while ago

So now we can actually convert regular EXRs found off PolyHaven and co. to a Bevy format

[foggy basin]

Could we assume that most users would want this? Is this something that also requires changes in the bevy code itself?

Trying to think about how this would be configured and what the options could be

[twilit dew]

So, I have three big ones in mind, corresponding to those 3 oldest issues

Let's start at mips

Mips are something every 3D dev wants, otherwise they get this kind of aliasing

Unfortunately, the "classic" formats people know like PNG and JPG don't support mips

The "canonical" format for those in Bevy is KTX2

Which not many viewers support. e.g. you cannot just double click on the files to see them

So there is some buy-in cost. Most people will probably not want KTX2 files in tree, but only in the released game

Now whether it needs Bevy config, there are two situations

If you simply load the image, then the ending has to match. So, you may have to write something like this:

let path = #[cfg(feature = "dev")] { "foo.png" } #[cfg(feature = "release")] { "foo.ktx2" };

Fortunately, the CLI helps a lot with these features 🙂

But as you see, its not exactly plug-and-play

The other situation is glTFs referencing textures

That part is much better

Rob Swain has had a brilliant idea for that

You can just change the reference inside the glTF file, and Bevy will happily follow it

So, if you load a glTF file referencing PNGs, you can just edit the glTF itself to point to KTX2 files after baking. No changes in Bevy needed!

[foggy basin]

Tbh I previously thought mipmaps are generated at run-time (or rather startup/loading screen)
So it's more common to preprocess them?

[twilit dew]

Depends on the engine. For prototyping, it's often done at runtime / loading, yes

[foggy basin]

But we probably shouldn't modify the original asset while processing assets right? How would the CLI handle this?

[twilit dew]

But if you're touching the textures anyways, they're usually compressed while on it. And that takes a while. But it makes it faster to process them on the GPU at runtime.

[twilit dew]

Yep. Again, multiple possibilities. On the release workflow, I would like to just overwrite the original files, as that is running on a GitHub runner's local copy anyways

Locally, you can work with symlinks

Have an assets_raw and assets_baked dir or something like that, where assets_baked is in your .gitignore

Then have a symlink from assets to assets_raw or assets_baked

This is not something I would advise for the CLI, as this completely breaks down on Windows

So instead, it seems to me like the simplest solution is to just create a dir called assets_baked and let the user deal with it

You can also use an env var to set the assets dir to be used BTW

lots of stuff the user could do: symlink, env var, configure the plugin to point to assets_baked, etc.

Again, I think it's enough for the CLI to generate a assets_baked 🙂

Does that make sense so far?

[foggy basin]

So it would be a full copy of assets, but with e.g. the gltfs replaced with the processed version?

[twilit dew]

Exactly

[foggy basin]

I think the CLI will also have to have a cache folder, so we can hash the original assets and only reprocess when things changed

[twilit dew]

woah that would be really cool for iteration speed locally

[foggy basin]

Which is kinda what the the bevy built in processing does if I remember correctly

[twilit dew]

Oh, there is one more issue about mips.
When generating KTX2s you need to differentiate between diffuse textures, linear textures, and normal maps

This means using some kind of heuristic for "regular" images, like looking at their names

But again, trivial for glTFs, as they already tell you how they use their textures 🙂

https://github.com/superdump/klafsa

Here's the relevant tool

[foggy basin]

So all in all this sounds like a high effort high impact situation

[twilit dew]

Agreed for arbitrary textures. For glTFs, I believe it's fairly low effort. Basically just wrap klafsa.

So that's mips

Now cubemaps

Cube maps are needed for skyboxes and environment lights. Both are really really important in 3D. But when you google for them, you will almost always find HDRis or EXR files. Bevy can't read those directly, yet.
The authority here is @tight shore. I believe he's planning on implementing direct HDRI / EXR cubemap reading in Bevy. In the meantime, he already implemented a very easy to use tool here: https://github.com/mate-h/blender-envmap

That one just spits out Bevy-compatible cubemaps

Once you have those, there's no reason to keep the original HDRis around, to my knowledge

So implementing this is low effort, high impact. BUT there's a chance it's obsolete soon anyways. I'll let mateh speak on that

Last one is meshlets

This is the one that cannot be solved by third party tools

Meshlets are their own custom format for Bevy's meshlet feature

You need to create them from Bevy Meshes

Those only exist at runtime, they intentionally have no form on disk

So you need to create a little Bevy app to even be able to process meshes to meshlets

This barrier means that nearly no one I know ever worked with meshlets in a real project

Which is a shame, given what they offer

In a nutshell, in 3D you at some point in your project will reach a stage at which your scene runts too slow because all your stuff uses a lot of triangles

The solution for that is historically to create LODs, those are 3D models that have lower resolution. Then you use those at a distance where the player doesn't notice.

Trouble is that those need to be made by hand

You can easily end up with like 4 LODs for a given model, so this is a lot of time you need to invest

Meshlets / Nanite is revolutionary in that it simplifies the geometry automatically

Even better, it simplifies it where needed. If a part of a big mesh is far away and another part of the same mesh is close by, only the far away part gets simplified

That is my nutshell explanation of meshlets

So this is really really valuable for a subset of developers. Namely, those that use 3D with enough models and / or enough details and / or enough render distance to suffer performance issues
Edit: also, meshlets allow culling parts of the mesh that are not visible!

[foggy basin]

(I'll be afk for a while, will be back later. Thanks for putting this together!)

[twilit dew]

But, as I said, they're have quite a bit of a barrier of entry in Bevy

Given that the vast majority of 3D Bevy devs I've talked to use glTFs for their models, I believe the CLI could do a great service if it had some way of converting a glTF to a meshlet mesh

Since glTFs are exported data and not authoring data, you can also safely delete the original glTF after this process

Well, of course you should let the user decide and not just delete stuff without them knowing

But I mean that in contrast to the texture mips, you don't need a separate assets_baked dir

If you're fine with putting the glTF in your repo, you should be fine with putting the meshlet in the repo instead

Now the effort of all this is probably the most annoying, since you have to wrangle the asset preprocessing API. These parts of Bevy are not well-explored and you might run into things that don't work, or work differently than you expect, or have hidden limitations, etc.

[trail shale]

now public!

[twilit dew]

So I'd say that this is unknown-effort (maybe low, maybe high, I just know it's annoying), and mid-to-high impact. The important thing to keep in mind is that there is currently no other tool that is capable of doing this, to my knowledge. There is https://github.com/zeux/meshoptimizer, but it uses a different meshlet representation than Bevy and I think Jasmine didn't manage to reconcile those. But I may be out of the loop

To expand on this, this is low (or even zero) impact for people just prototyping things, and high impact for people doing something in 3D that they want to publish

And that's my TED-talk 🙂

So if I had to pick one, I'd be most interested in meshlet conversion, followed by mip generation, followed by cubemap (cubemap is this low because mateh did a fantastic job on his current tool, otherwise this would be at the top)

[twilit dew]

@stone steppe mind correcting any mistakes I made in my assessment? Context is asset preprocessing with the Bevy CLI alpha

@slim pine We're discussion asset preprocessing in the CLI alpha 🙂

Probably not entirely relevant until we have first-party collider types in Bevy, but still worth mentioning

Also yoinking in @shrewd monolith

[shrewd monolith]

oh yes it would be so convenient to be able to process audio files into ogg vorbis

for probably 95% of audio files, ogg vorbis is the correct choice, but it can be really annoying to convert a heap of wav files to it, especially during development

My DAW of choice can't even output oggs

[twilit dew]

Forgive my ignorance: Is this not something one can just throw ffmpeg at?

[shrewd monolith]

yes
converting to oggs would just be convenient
this is the kind of thing Unity and Godot handle with their asset importing, but maybe it should wait for the editor?

[twilit dew]

aaah gotcha

So the bevy cli could in principle just wrap ffmpeg for this

sweet!

[shrewd monolith]

yes, or we could use symphonia too

which might be a little more reliable (no runtime tool dependencies)

[twilit dew]

double sweet!

[worthy widget]

Symphonia only decodes audio. It doesn't do encoding.

Encoding is actually leagues harder than decoding. Which is why there aren't many projects that do it.

[twilit dew]

encoding or encoding?

I assume you meant encoding is harder than decoding 😛

[worthy widget]

Lol, typo

Although actually there appears to be quite a few crates that wrap the reference vorbis encoder. https://lib.rs/search?q=vorbis+encode

(ogg is the file format, whereas vorbis is the actual encoding/decoding algorithm typically used in ogg)

Namely this one: https://lib.rs/crates/vorbis_rs

[shrewd monolith]

i wonder what the policy for C wrappers is in the cli
is that more or less sinful than using ffmpeg? 😅

[worthy widget]

I guess the main advantage is that the user won't have to install the ffmpeg dependecies.

Also, don't forgot about the Opus codec. It's higher quality than vorbis for the same bitrate.

[limber wedge]

If possible i would like to avoid cli tools that aren’t very well established in the ecosystem. The end goal is still to be upstreamed and i think we should avoid bus effects if possible. (Not only related to ffmpeg vs rust impls)

[twilit dew]

Hmm that's a bit of a chicken-vs-egg problem imo. We currently don't have any real kind of asset preprocessing beyond "write a python script yourself lol", so there kinda cannot be any well established tools

[worthy widget]

https://lib.rs/crates/audiopus https://lib.rs/crates/opusic-c

Though personally I would be fine with relying on ffmpeg. It is an industry standard library after all.

[twilit dew]

Oh are you referring to something like "we should use ffmpeg instead of some homemade Rust port"?

[limber wedge]

Yes but then i think we should create our own / yoink it

[limber wedge]

For that one perhaps

For the asset stuff you showed two repos from active bevy maintainers so i think it would make more sense to just include it rather then depend on it i guess

[twilit dew]

Fair enough, though I also think Bevy already has a lot of NIH 😬

Which makes sense for C / C++ stuff, you cannot get that on Wasm, you have to RiiR it

But IMO the CLI doesn't need to have those restrictions

[shrewd monolith]

(Can you not make threads in a forum channel?) anyway didn't this actually just get resolved with the C ABI fix for Wasm? (I guess it's still a toss-up whether the C dependency can work without the C standard library though.)

[twilit dew]

Which is to say, I would rather depend on wrapping a battle-tested existing tool than doing our own thing

Though maybe you're agreeing with that @limber wedge? Not sure I completely got you 🙂

[twilit dew]

You cannot. But TIL, that's interesting to note 👀

[limber wedge]

Yes 100% use battle tested tools if possible!

[twilit dew]

Ah okay, then we're in agreement 😄

I think I just misread your earlier comments, don't mind me

[worthy widget]

Yeah, ffmpeg would make it easier to support both vorbis and opus.

[limber wedge]

Ment more that if its not a well known tool and its rather small i think it could make sense to do it ourselves so its its under the bevy org and that one has a lot of active maintainers 😄

[worthy widget]

Though keep in mind ffmpeg has a steep learning curve (it's meant to handle every file container format and codec under the sun, so there are a lot of parameters).

It would be handy to have an easy-to-use wrapper around ffmpeg that can automatically convert your audio assets into ones best suited for games.

[foggy basin]

Ia ffmpeg available in Windows environments? I assume yes, because its basically the tool for media conversions?

[twilit dew]

No clue, but I would also hope so?

[vast vine]

yes

[foggy basin]

In that case, the audio processing might actually be a decent starting point for the asset processing capabilities.
Sounds relatively easy to go through all audio files and convert them to opus or vorbis ogg.
Then we could use it to set up the workflow and then refine / extend it iteratively

[shrewd monolith]

I think this was already mentioned, but just to clarify -- this would be non-destructive conversion, right? Like in a cached asset folder or something?

[twilit dew]

Imo it should be non-destructive by default with a flag to make it destructive

[foggy basin]

Right now I imagine that we specify a target directory. If its the same then its destructive and if it's different then not

[twilit dew]

That’s also a good idea 🙂

@shrewd monolith it shouldn’t go through all audio, right?

[foggy basin]

And then it should be possible to define the asset folder to use in the CLI config, then you could for release builds define the processed asset directory

[twilit dew]

IIRC some things are better in WAV?

[foggy basin]

Well, that complicates things

Do we need glob-like ignore patterns?

[twilit dew]

You can probably safely go through e.g. the entire sfx dir

I imagine that users would have their wavs in a different dir, since they are semantically different, think music vs sfx

@shrewd monolith please correct me

[shrewd monolith]

well very short sfx are actually a prime wav candidate, whereas music is often so big it would be irresponsible not to compress it!

[twilit dew]

Ah whoops 😄

[shrewd monolith]

(short sound effects benefit less from compression, and since they're often played in rapid succession, using an easily decodable format can sometimes make sense)

[foggy basin]

I'm thinking more and more the first iteration will probably not handle all use-cases :D

[twilit dew]

Anyways, a simple solution would be to leave it up to the user to organize their files and just let them point the CLI at some dir

^ same for meshlets btw

[twilit dew]

Well, the version that handles all usecases is presumably what bevy_asset should provide

The API hole is in having something that works easily for the 95% of users

For example, I believe a non-goal for the CLI is to define a file that lists all assets and how to process them. That is something we already conceptually have: .meta files

[foggy basin]

One question would be if we should take the time to build the CLI solution or if we should invest that time into Bevy assets itself.
Would the CLI be a temporary fix anyways or will there be usecases that we always want to be handled by the CLI?

[foggy basin]

@limber wedge just have minor comments on https://github.com/TheBevyFlock/bevy_cli/pull/540 now, I already approved so you can merge it when you're ready :)

[foggy basin]

I'm starting to post a bit about the Bevy CLI development, to raise a bit awareness also outside this working group :)
https://bsky.app/profile/opensource.timjen.net/post/3lw35k23fqk2m
I also plan to finish setting up my blog soon-ish, for more in-depth posts

[twilit dew]

In an ideal world, the builtin preprocessing would have so many builtins that as a user I should be able to just write a little meta file and be done with it. In that sense, I believe that the CLI preprocessing is ultimately temporary.
But the only person who really pushed for preprocessing was Cart, as part of the infamous Assets V2 monster. Since he has bigger fish to fry, I believe it will be long until preprocessing will ever be touched again in-engine. Of course, there can always be a random contributor who is passionate about that and spearheads development, but I wouldn’t count on it.
So I'd personally estimate we are at least one, probably more than two years away from having a good builtin preprocessing pipeline API that is batteries included, i.e. I don’t need to go and write code for destructuring glTFs and such by hand.

Given that many CLI preprocessing tasks can right now be implemented as "wrap this other command", I believe we can get something very usable out very soon if someone takes some time to implement them

Also, some features like meshlets essentially don’t really exist for most users while we are stuck without preprocessing

[stone steppe]

They do have a disk format, it's just not stable or meant for anything besides bevy. The use case is basically having bevy process the assets for you, and then you ship them. You're not meant to move them around or use them anywhere else.

[stone steppe]

Well, they're also not bug free :P. I think there's some new LOD bugs after the recent BVH work too 🙁

[stone steppe]

Yeah, I would absolutely love that. Either as part of bevy_cli or an asset processor or something, idk which.

[stone steppe]

Meshoptimizer isin't really an end to end tool, they provide some APIs you can use to build something like Nanite yourself though (some of which bevy uses)

[stone steppe]

Think I got them all. Overall pretty accurate. I will say that the main blockers I had when I tried to do this in https://github.com/bevyengine/bevy/pull/13431 is that:
*glTF is a pain to write. It's easy enough to add the processed meshlet mesh appended to the file, but removing the original mesh and rewriting all references to it to the meshlet mesh is really really difficult

• We don't have a clear path towards processing glTFs. E.g. you can process the glTF to convert meshes to meshlet meshes, but then what about all the images in it? How do you map those to seperate assets to process? Might not be as big a deal for the CLI as it was in an asset processor

[rocky oxide]

I would appreciate your reviews on this please 🙂

[foggy basin]

I created https://github.com/TheBevyFlock/bevy_cli/issues/546 to deal with the getrandom problem

[buoyant jasper]

Hi folks! Is there any ETA for a new (alpha) release of the CLI? I'm still pinned to a specific commit that has the wasm-opt parameters feature in it and it would be nicer to just depend on a tag.

[pale viper]

I think we should be due for a release very soon! There's definitely a lot of features and fixes that we should get out to the world

I definitely want to check in with @foggy basin and @limber wedge, though, since they're more involved with the CLI side of things than I am

I think there's a good chance that v0.1.0-alpha.2 will be the last release before we get upstreamed, though

[foggy basin]

I'm not opposed to release soon-ish!

[vast vine]

Has there been talk about automated migrations using the cli? I think it might be possible to at least automate some migration path using a tool like https://ast-grep.github.io/ It's a rust based project that can transform patterns to a new pattern. It uses AST instead of just regex which means it's a lot more flexible. It will likely require manual work, but the community could slowly build up migrations and it would still be better than nothing.

I don't know if ast-grep can be used as a library, but I used it at work to do a bunch of bevy migrations

[foggy basin]

Tbh I'm still a bit fuzzy on how exactly the upstream process will work.
If we completely stop work on the prototype until everything is upstreamed, if/how we transfer commits to retain all original contributors (also for small fixes), how the CLI repo will operate once it's upstreamed (e.g. who will have merge rights and what will the review policies be) and how we would chunk up the upstream PRs

[foggy basin]

It has definitely been discussed before, but not in too much detail AFAIK.
So far I think it mostly focused on integrating more deeply in the Rust syntax, basically similar to how the linter is set up.
Until now, it has been dismissed as too challenging IIRC.

But I definitely see a lot of value in it if we could get it to work. I guess it also wouldn't have to get you 100% there, 80% would probably already help a lot

Here's an old issue on the topic: https://github.com/TheBevyFlock/bevy_cli/issues/14
But that's over a year ago already, so things might have changed

[vast vine]

Honestly, just having repository of ast-grep files preconfigured for a specific migration would be super nice, but having that as a feature of the cli would be even nicer

I don't think it would ever be a full migration, but at least handle the trivial migrations

[buoyant jasper]

Was the idea of just transferring the repo to the org considered? That would help in all these concerns I guess (user access, commit history, etc.)

[foggy basin]

I first thought ast-grep was JS, because they advertise to install it via npm. That would have been quite challenging to integrate.
But I see now it's Rust and we already use several third party Rust CLI apps. So that part would be plausible

[buoyant jasper]

But I don't know what would be the cons of that. To me it makes sense to maintain it as a separate thing.

[foggy basin]

I think @trail shale preferred to upstream piece-by-piece to evaluate each feature individually.
But there was not too much discussion on the upstreaming yet

[vast vine]

Yeah, that's why I mentioned it. I've used other alternatives in the past that weren't rust based but I have a neovim plugin for it now and it's super useful. I've used it extensively for my 0.14 to 0.15 migration at work and it was so nice for all the trivial migrations. The big question mark would be if it's available as a library or not

But I guess even if it's not, since it can be installed through cargo it woudln't be too hard to install automatically and call out to it

[foggy basin]

Sometimes, calling the CLI interface is preferrable to using it as a library, especially if the library is large.
In most cases, the CLI will be installed with all features enabled, so saving time on that part can be quite beneficial. And the migration part wouldn't be needed in CI so it would just add bloat there

[vast vine]

Right, good point

[foggy basin]

Yea we already have a nice system to automatically install missing packages

[vast vine]

Oh, neat, didn't know that, even better

[foggy basin]

Since we need wasm-bindgen, wasm-opt, etc

[vast vine]

I think I should start a separate intiative to have a repository to host ast-grep files for specific migrations in a repo and then eventually letting the cli use that. That way we can keep the cli more focused for now

[foggy basin]

@vast vine would you like to open a new issue on the CLI repo regarding the migrations?
I would be especially interested in reference configs that you used for the ast-grep tool if you have any available

[foggy basin]

That also works!

The migration files would be most of the work anyway, calling the CLI tool with the correct args seems trivial in comparison

[vast vine]

The issue is since it was just for me I did all of it very locally and didn't keep anything around 😅

I'm planning on being a bit more structured with it once I migrate out work codebase to 0.16

[foggy basin]

Unfortunate, but understandable :D

The "good" part about migrations is, even if they take a long time after release to put together, there would probably still be a good amount of projects who could benefit from them

[vast vine]

Yeah, exactly, I'm hoping this help reduce my workload if I don't have to come up with new migration file on my own every time. And as more people use it we'll likely be able to generate them fairly quickly

#1404563804947353742

[sturdy tapir]

Opinions from those who have dealt with rustc drivers?

[whole narwhal]

Yes but only if you install it yourself. Might be in path from some other utils but they sometimes ship very old versions so it is dangerous to rely on it unless the cli brings it with it.

[whole narwhal]

ffmpeg could be installed by using winget on Win11, even without admin permission: winget install ffmpeg . Not sure about Win10.

[pale viper]

This is definitely possible! What kind of reflection information do you all need?

[foggy basin]

"I want to build this Bevy example for the web, how do I do it"?
CLI "I got you bro"

debug: running: `cargo build --config profile.web.inherits="dev" --config profile.web-release.inherits="release" --config profile.web-release.opt-level="s" --config profile.web-release.strip="debuginfo" --config dependencies.getrandom_02.package="getrandom" --config dependencies.getrandom_02.version="0.2.12" --config dependencies.getrandom_02.features=["js"] --example breakout --profile web --target wasm32-unknown-unknown`
debug: with env: RUSTFLAGS= --cfg getrandom_backend="wasm_js"

[pale viper]

Heck yeah! That getrandom setup is going to be super nice

[foggy basin]

A bit unhinged, but it works!

[limber wedge]

i will update my pr and review yours tomorrow morning Tim! it has been sooo hot here that i dont really feel like thinking in the evening ^^

[sturdy tapir]

Type data for the struct fields, their names, possibly the size/layout data incase need to fully load a specific component, not sure what else but I'm sure I'm forgetting something.

[dusky onyx]

This is still nothing compared to the gcc commands emitted by an average cmake project 😄

[pale viper]

If theoretically you had this data in a file, how would you look up the data for a specific type? By its name? Its path? Its type id?

And what specifically do you need this reflection data for? (In the terms of the editor)

[sturdy tapir]

Assume the editor loads it like it does bsn
Its purely fill in info gaps for bsn
So editor can list all the fields of a component even if the bsn doesnt.

This is cause bsn spec doesn't require things to be exhaustive
So gotta get info elsewhere

[foggy basin]

@silk delta I now have something testable for the getrandom stuff.
It's still blocked by another PR, but unless you have other rustflags defined in your project it should already work.
If you want you can take a look here: https://github.com/TheBevyFlock/bevy_cli/pull/547
I included instructions on how to try it out, but let me know if you have any questions!

[silk delta]

I will take a look tomorrow

[pale viper]

I don't know anything about how the editor handles BSN, so unfortunately this doesn't help me :(

Are you trying to use reflection to auto-complete BSN in the editor?

[sturdy tapir]

yes thatd be the first big usecase
Bsn will get loaded into the editor in a pre-world state (still waiting on exact details from cart but he likens it to a ast of the bsn)but if a loaded file doesnt contain all the data the editor needs for a component we need to fill in the gaps with reflection data, but rn theres now way to get said data without a full successful compile of the user's game, so want to explore dumping that data via a rustc driver

[twilit dew]

Ooooooh rustflag merge landed 😄 🎉

[limber wedge]

im fighting against the heat

[twilit dew]

I'm losing

Just went on galaxus for ACs

nearly all sold out

Send help

[limber wedge]

Lol i have one fan that is so useless and super loud. Not sure if its making me more crazy then just taking the heat

[twilit dew]

hehe

[twilit dew]

This is extremely poggers, as the twitch people would say

No more debugging my stuff for 30 minutes only to discover the issue was rustflags

thanks

[limber wedge]

No worries!

Hope it works for your config too lol

[twilit dew]

I'll try once the multithreading stuff merged main into the branch 🙂

[limber wedge]

Yes that one is soo cool! Looking at it right now

[rocky oxide]

We need to send the Europeans heat pumps

[silk delta]

Send ice. lots.

We will send back steam in return

[foggy basin]

Well just as a disclaimer, Rustflags can still be the issue!
It only merges bevy rustflags with the resolved cargo ones, but not the cargo rustflags with each other
(@limber wedge correct me if I'm wrong)

[twilit dew]

yeah that's more than enough 🙂

[limber wedge]

it just adds all the rustflags defined in Cargo.toml to the once that get resolved from cargo config

[twilit dew]

yeah that's exactly what I need: add bevy run related flags while not wiping my pre-existing setup

[foggy basin]

Which is still awesome, I love how it unlocks both the multi threading and the getrandom fix!

[limber wedge]

yes and if you have a project specific one you could add it to Cargo.toml while keeping you ~/.cargo/config.toml "clean"

or obv create a local cargo/config.toml

[sturdy tapir]

its hot enough here send us dehumidifiers

[foggy basin]

It's now merged!

Let me know how it works for you :)

[whole narwhal]

What is the current incantation to run a sample in web including getrandom? bevy run -r --sample animation_graph web --open gives the usual getrandom problems. Thought that was included in current main?

[foggy basin]

The getrandom PR is not merged just yet :)
But there are instructions on how you can try it out if you want to:
https://github.com/TheBevyFlock/bevy_cli/pull/547

[whole narwhal]

Thank you!

[whole narwhal]

This is so much easier, works like a charm

[silk delta]

Does the CLI work with building an existing project?

Because I might test it with some bevy_rand examples

[foggy basin]

Yes, it should!
If you want to use custom web assets like a custom index.html, we currently expect them to be in a web folder though.
But it also rolls it's own index.html if it can't find a custom one

[twilit dew]

nope :/

Added this to my Cargo.toml:

[package.metadata.bevy_cli.unstable]
web-multi-threading = true

but bevy run web is not running with audio

Oh wait I need -U multi-threading

can I enable that for all my web builds automatically?

hmm still not working

I'll set up a branch of foxtrot

okay it works now, idk why I blame caching

@foggy basin it all looks good, I just have one concern

RUSTFLAGS=--cfg getrandom_backend="wasm_js" --cfg getrandom_backend="wasm_js" --cfg web_sys_unstable_apis -Ctarget-feature=+bulk-memory,+sign-ext,+nontrapping-fptoint,+atomics -Zshare-generics=y -Zthreads=8 -C target-feature=+atomics,+bulk-memory

This is my merged RUSTFLAGS

What happens to the two -Ctarget-features?

Do they get merged by rustc or does the second overwrite the first

I assume they get merged

But I'm not sure

[foggy basin]

Well 😀

[foggy basin]

Me neither

We could try to detect the duplicates and filter them out, but it's probably not trivial given the different Syntax you can use

[twilit dew]

let me try doing one where I set one to atomics and one without atomics

[foggy basin]

And actually for the get random backdnd flag I already implemented that it shouldnt add it if its already included but looks like that doesn't work lol

[twilit dew]

https://github.com/TheBevyFlock/bevy_cli/pull/547

not merged yet 😉

I'm using main

[foggy basin]

Ah, right!

So there is still hope for my code 🤞

[twilit dew]

looks like it merges!

RUSTFLAGS=--cfg getrandom_backend="wasm_js" --cfg getrandom_backend="wasm_js" --cfg web_sys_unstable_apis -Ctarget-feature=+atomics -C target-feature=+bulk-memory -Zshare-generics=y -Zthreads=8

this here has atomics on

let me flip the order, just to make sure

[foggy basin]

That's... unexpected?

[twilit dew]

is it? --features foo --features bar also merges

but works with --features foo,bar too

[foggy basin]

True but features are also additive and rustflags are not :P

[twilit dew]

fair

[foggy basin]

But I won't complain if it merges :D

[twilit dew]

would have to check source to be sure

[twilit dew]

I get this again

which sounds good 🙂

BTW how come the CLI doesn't activate --cfg web_sys_unstable_apis?

I heard that's also needed?

But idk 😄

[foggy basin]

That flag is new to me 🤔

Maybe its only needed when you use the web sys crate?

Yea I see it in the web-sys docs:
https://docs.rs/web-sys/latest/web_sys/
I think its not used in Bevy?

[twilit dew]

Oh I remember

It was needed for bevy_egui in Wasm

Or Hanabi

one of those

[foggy basin]

For multi threading or something else?

[twilit dew]

no, something else

Can't remember

But it's been a while

I think maybe clipboard support?

Something like that

Anyways, nothing relevant to the CLI 🙂

Ah btw, are you aware that these options here make the generated Wasm faster?
"-Ctarget-feature=+sign-ext,+nontrapping-fptoint"

Don't ask me what they do lol

But they but passed around (in addition to +bulk-memory, but I think that is the default now) during the jam for people to improve their performance

And I can confirm it worked for us

[limber wedge]

so are rustflags good?

[twilit dew]

looks like it 🙂

At least on my end, it seems good

I'll try an itch.io release next

[limber wedge]

[twilit dew]

so it runs on the GH runner

[twilit dew]

Well now it stopped working again 👀

Can someone try Foxtrot's main?

with bevy run web

It's not playing audio in the browser for me

RUSTFLAGS=--cfg getrandom_backend="wasm_js" --cfg getrandom_backend="wasm_js" --cfg web_sys_unstable_apis -Ctarget-feature=+bulk-memory,+sign-ext,+nontrapping-fptoint,+atomics -Zshare-generics=y -Zthreads=8 -C target-feature=+atomics,+bulk-memory

It's definitely merging the RUSTFLAGS

Is it maybe not settings the headers?

It's probably also overriding my config.toml's build-std, come to think of it

[limber wedge]

can only test tomorrow sorry

i think --verbose logs the headers?

[twilit dew]

I found the source of the bug

drum roll

My headphones turned themselves off ._.

[limber wedge]

oh

[twilit dew]

🎉

[limber wedge]

dont forget to open an issue for that (;

[twilit dew]

can confirm that bevy run web works with the new option on main when used in conjunction with the firewheel web backend hahaha

[limber wedge]

nice!!

thanks so much for testing!!

[twilit dew]

thanks for implementing it 😄

Itch.io release should be ready in like 20 mins

[twilit dew]

Update: works !

[foggy basin]

Interesting, that's new to me!
But I think we'll have to be careful about enabling unstable flags by default in the CLI 🤔

[twilit dew]

I don’t think these are unstable? Not sure

[silk delta]

As a heads up, I tested my new bevy_rand examples with the getrandom CLI branch. Works fine, no issues building

[twilit dew]

That’s great 😄

[foggy basin]

Excellent, I'll try to finish up the PR this weekend :)

[silk delta]

Is the next CLI version being targetted for Bevy v0.17? If so, I might put a reference in my example docs on how to build with the CLI

[limber wedge]

The CLI can be used with any bevy version

[silk delta]

Aight, so then I'll just wait until the getrandom PR gets merged, since it is worth mentioning it in any case

[pale viper]

Just a heads up: I’m going to be a bit busy in the next few weeks! (I’m moving to college!) I’ll keep up with Discord, but probably won’t have time for Github until things settle down

Let me know if y’all need anything, though! :)

[limber wedge]

ENJOOY and good luck! Hope the move goes smoothly

Is the college near your parents place?

[pale viper]

It’s a bit of a drive, so I’ll be living in dorms, but it’s not so far that I’ll be stuck in case there’s trouble

I’m excited, it’s going to be fun!

(And there’s some cool cybersecurity classes I’ll be taking there too)

[limber wedge]

Yes i think so too!

Im studying cyber security

[stone steppe]

I'm curious, is this UMD?

[pale viper]

No way! We’ll have to swap notes at some point :)

[pale viper]

No, but I did definitely consider applying to Maryland. The campus is pretty, and I hear the comp sci program is very strong

[stone steppe]

Ah, I went to UMD for cybersecurity lol, I was curious if it was the same place

[foggy basin]

The getrandom PR should be ready for review now :)

[limber wedge]

Nice will take a look tomorrow!

is there a way to also disable this behavior? (not sure if it needs to exist since its required for getrandom)

[foggy basin]

When you manually add the feature or manually configure a backend through RUSTFLAGS or if you don't depend on getrandom it won't add anything

[silk delta]

As long as getrandom is in the deps and gets used, you'll probably want that behaviour for web builds

For custom builds like embedded, that's probably when you want your own setup anyway

[limber wedge]

ah i see makes sense!

[foggy basin]

Before tackling any new bigger topics for the CLI, I plan to do some polishing and cleanup in preparation for a potential new release

For example, I finally want to have build times and binary sizes logged at the end of the command

[pale viper]

Totally! I think things are shaping up nicely, looking at the changelog

@limber wedge I have one last change request for https://github.com/TheBevyFlock/bevy_cli/pull/529 (it's just docs), then I want to merge it

[limber wedge]

Yes will do!

[limber wedge]

looking at https://github.com/TheBevyFlock/bevy_cli/pull/547 in one of my projects i also used bevy_rand:

bevy_rand = { version = "0.10", features = ["wyrand"] }
rand_core = "0.6"
rand = "0.8"
```  and here it does not work is this expected? 

```error: The "wasm_js" backend requires the `wasm_js` feature for `getrandom`. For more information see: https://docs.rs/getrandom/0.3.3/#webassembly-support```

[silk delta]

Kinda weird, but I tested it with a bunch of new examples I put together and that CLI PR build worked fine

Oh, using older bevy_rand version hmm

Wait, it should still work

[limber wedge]

yea i used to set ```toml
[target.wasm32-unknown-unknown.dependencies]
getrandom = { version = "0.3.2", features = ["wasm_js"] }

[dependencies]
bevy = "0.16"

bevy_rand = { version = "0.10", features = ["wyrand"] }
rand_core = "0.6"
rand = "0.8"
``` just this in an new project

debug: running: `cargo build --config profile.web.inherits="dev" --config profile.web-release.inherits="release" --config profile.web-release.opt-level="s" --config profile.web-release.strip="debuginfo" --config dependencies.getrandom_03.package="getrandom" --config dependencies.getrandom_03.version="0.3.3" --config dependencies.getrandom_03.features=["wasm_js"] --bin test_project --profile web --target wasm32-unknown-unknown`
debug: with env: RUSTFLAGS=-Zshare-generics=y -Zthreads=8 --cfg getrandom_backend="wasm_js"```

[silk delta]

Also, if you are using bevy_rand from v0.10 onwards, you can use latest rand

And it will be made compatible with bevy v0.16

[limber wedge]

oh good to know thanks! but it should still work

[silk delta]

That pr should set the feature for both versions of getrandom in any case

[limber wedge]

yea i will check maybe while reviewing i can spot it

[silk delta]

Also, don't you just love this getrandom update?

[limber wedge]

seems pretty... random

[twilit dew]

yes, I feel very security

[pale viper]

If you haven’t been watching #engine-dev, there’s been a bit of discussion on the CLI’s getrandom support

I think we should consider releasing soon, as this feature is so big that some people are installing the CLI from main

[limber wedge]

Its not yet on main but yes

[pale viper]

Ohhh right 😅