bevy_cli

[pale viper]

And I don't think com.google.android.gm exists; it looks like a Java package name ^^

[limber wedge]

should be fixed with: https://github.com/TheBevyFlock/bevy_cli/pull/404

[pale viper]

I'm making a little proc-macro library to help with merging configuration, since both the CLI and linter use it

Hopefully it will make things a little less verbose :)

[limber wedge]

#[derive(Merge)]

[pale viper]

Lol exactly

[limber wedge]

i think what i would like to know is why they are not using the cli. I would assume most attending are pretty invested in bevy and know about the cli so it would also be interesting to know what the cli would need to attract them.

same for the linter like what are some lints that would benefit them the most

[foggy basin]

Honestly I wouldn' be too suprised if some don't know about the CLI, or at least about what it can do. We haven't advertised it much

[molten merlin]

I link directly to the CLI as a supported new project method, so this page is probably sending the traffic: https://bevyskein.dev/docs/quickstart

[foggy basin]

Another polishing PR, aligning our logging style to be closer to cargo's
https://github.com/TheBevyFlock/bevy_cli/pull/410

[limber wedge]

@pale viper Do you wanna take this into 0.4.0 https://github.com/TheBevyFlock/bevy_cli/issues/338 ? otherwise (or maybe even then) i would put the bevy_lint behind the rustup feature flag in the cli.

[pale viper]

I have a branch where I'm working on it, so we can add it to the milestone :)

Although the branch just makes Rustup optional

The branch is rm-rustup-and-driver-path, although I'm not going to open a PR until I finish working on the #![register_tool(...)] RFC with Jyn and publish mergeme v0.1.0

[limber wedge]

Oki yea lets add it then!

[limber wedge]

is the BevyLintCallback:config callback being run multiple times? @pale viper

[pale viper]

Nope, it should only be run once!

[limber wedge]

yea that was my thought too but if i add a dbg! log i see it multiple times

[pale viper]

Cargo will execute bevy_lint_driver multiple times to compile a crate and its dependencies, though

[limber wedge]

o

[pale viper]

That may be what you’re seeing

[limber wedge]

yea i think thats it!

[pale viper]

Print the CLI args / PID to see if they’re different executions or not

[limber wedge]

good idea, will do tomorrow. Just wanna try to avoid creating the same linter config multiple times especially if we use cargo-metadata to parse out the package / workspace metadata

[limber wedge]

so yea its just that

[pale viper]

@foggy basin do you have any plans / ideas for the CLI release process? Would you like me to draft up a release checklist, similar to what the linter has?

[foggy basin]

I think the most important part would be a review by the maintainers.
A release checklist would be great!
Would be really nice if we could do the first release soon to unblock the cargo binstall installation

[limber wedge]

Was looking into using cargo-metadata to read [package.metadata.bevy_lint] https://github.com/TheBevyFlock/bevy_cli/pull/415 would welcome some feedback, in my opinion its not worth it but good chance i missed a better way to do this

[pale viper]

Thanks for checking it out! While it may be possible to simplify, I agree with your assessment that we should probably stick we toml. I'm closing your PR and closing the issue as "not planned"

[limber wedge]

Thanks!

[lapis fjord]

How can I integrate bevy_lint into my rust-analyzer workflow? Like, making the messages it prints show up in my editor

[limber wedge]

I think it should be possible by setting this: https://rust-analyzer.github.io/book/configuration.html?search=OverrideCommamd

[twilit dew]

Then cargo check wouldn't work anymore though

[limber wedge]

Yes was about to say that. I have not thought about an elegant solution that works for bevy and none bevy projects

But i can look into it when im home

[twilit dew]

simple: replicate all of the cargo commands 🎉

cargo 2: bevy edition

[limber wedge]

Just only work in bevy projects

[lapis fjord]

Better to use it manually then

I still like using clippy

[limber wedge]

Tbh i think you could just completely replace cargo check with bevy_lint but i will check that

[pale viper]

You may be able to set the "Check Command" setting. See https://users.rust-lang.org/t/how-to-use-clippy-in-vs-code-with-rust-analyzer/41881/2, but write bevy_lint instead of clippy

"rust-analyzer.check.command": "bevy_lint"

[limber wedge]

Maybe you need to write another rfc but for rust analyzer now

[pale viper]

Ok: my PR adding cargo-binstall support to the CLI is ready! Please leave your reviews at https://github.com/TheBevyFlock/bevy_cli/pull/413 :)

[limber wedge]

it should be this in vscode```"rust-analyzer.check.overrideCommand": [
"bevy_lint",
"--message-format=json",
]

of if you use nvim ```lua
rust_analyzer = {
settings = {
["rust-analyzer"] = {
check = {
enable = true,
overrideCommand = { "bevy_lint", "--message-format=json" },
}
}
}
}

[pale viper]

@foggy basin @limber wedge I think we should release v0.1.0 of the CLI by the end of the week. The jam is in a little over 20 days, and we still need to allocate some of that time for the lovely bevy_new_2d people to update their template

Looking at the milestone, we have 3 PRs left:

1. cargo-binstall support
2. Installing linter through the CLI
3. Moving the docs from README.md to Github Pages

I think we definitely need 1, since it heavily reduces CI time (which is super valuable for people working on private repos).

I think we can cut 2 (not as important, a nice-to-have) and maybe 3 (big change, might break things) from the milestone, but what do you think?

[sturdy tapir]

I'd also like to have it to start work on integrating into the editor launcher

[limber wedge]

I would like to add 1),3) and this: https://github.com/TheBevyFlock/bevy_cli/pull/404 installing the linter with the cli is more a benefit for the linter ^^ but not need to get feedback for the cli

[pale viper]

You may be interested in 3, then. It publishes the API docs for the CLI to Github Pages, so you can view it online! But that can wait until after v0.1.0, since changes to Github Pages are immediate and don't wait for a release

[pale viper]

Oh yeah, #404 is a bug fix, we should definitely include it

[limber wedge]

And i think for most users the documentation is the most beneficial. Like we need to be more clear with how and what the cli merges (in regards to configuration)

[pale viper]

Got it! I'll review #404 on Thursday (busy until then with AP exams)

Maybe we can tentatively plan to release on Friday, and if something comes up, we'll release on Saturday?

[limber wedge]

No worries! Im also busy til Wednesday

And good luck!!!

[pale viper]

I know @foggy basin is at Rust week, so he's probably going to be busy. @limber wedge do you want to take a stab at the cargo-binstall PR?

[limber wedge]

Yes i think having a release on Friday or Sunday would be great

Yes sure

[pale viper]

Epic, I'm super excited! There's been so much great reception with the CLI already, and we haven't even made a release yet!

[foggy basin]

I will try to do a review pass today :)
Sorry, had very little time the past few weeks

[foggy basin]

Merged this and approved the linter install PR, feel free to merge it when you like :)

For the cargo binstall support and the docs page PR I need some more time, I hope to do that throughout the week

[near mist]

if this issue isn't too difficult to fix before 0.1.0, it would be important for UX imo: https://github.com/TheBevyFlock/bevy_cli/issues/327

we set RUST_BACKTRACE=1 when running dev builds in bevy new 2d, so this issue creates a backtrace into bevy cli's code whenever compilation fails

example:

error[E0599]: no variant or associated item named `Ignor` found for enum `LogLevel` in the current scope
  --> src/core/dev/ambiguity.rs:11:19
   |
11 |         LogLevel::Ignor
   |                   ^^^^^ variant or associated item not found in `LogLevel`
   |
help: there is a variant with a similar name
   |
11 |         LogLevel::Ignore
   |                        +

For more information about this error, try `rustc --explain E0599`.
error: could not compile `pyri_new_jam` (lib) due to 1 previous error
Error: Command `cargo run --features native,native_dev --profile dev` exited with status code exit status: 101

Stack backtrace:
   0: anyhow::error::<impl anyhow::Error>::msg
   1: bevy_cli::external_cli::CommandExt::ensure_status
   2: bevy_cli::run::run
   3: bevy::main
   4: std::sys::backtrace::__rust_begin_short_backtrace
   5: std::rt::lang_start::{{closure}}
   6: std::rt::lang_start_internal
   7: main
   8: <unknown>
   9: __libc_start_main
  10: _start

and in vs code you only see the backtrace in the terminal at first until you scroll up

[limber wedge]

i want to refactor our error handling for 0.2.0 anyway but i think for a first solution this should not be too hard

do you maybe have a good example and what you would expect the output to look like?

[near mist]

yeah, i'd expect it to be the same as cargo's output, only the compilation errors

error[E0599]: no variant or associated item named `Ignor` found for enum `LogLevel` in the current scope
  --> src/core/dev/ambiguity.rs:11:19
   |
11 |         LogLevel::Ignor
   |                   ^^^^^ variant or associated item not found in `LogLevel`
   |
help: there is a variant with a similar name
   |
11 |         LogLevel::Ignore
   |                        +

For more information about this error, try `rustc --explain E0599`.
error: could not compile `pyri_new_jam` (lib) due to 1 previous error

oh i read "and" as "of"

but any code with an error would be an example

[limber wedge]

thanks created: https://github.com/TheBevyFlock/bevy_cli/pull/424

i just don't know yet why i cant see the debug log but will check tomorrow ^^

[twilit dew]

I just noticed that the Bevy CLI does not use wasm-opt unless built with that feature. Any reason that that's not the default? Certainly just caught me by surprise!

[limber wedge]

I think it was initially due to compile times

[twilit dew]

Makes sense, I'll drop a quick PR then

(Since this is relevant to cargo binstalling the CLI on CI)

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

[lusty galleon]

I haven't been following super closely, but this surprised me a bit too.

Am I remembering right that bevy_cli used to use the wasm-opt library instead of cargo installing it? If so, I imagine the feature is a holdover from that time.

Right now it feels like something that should be a cli option and not a feature.

Ah, seems I am remembering right.

Switch to cli option also noted here: https://github.com/TheBevyFlock/bevy_cli/pull/303/files#r1988072784

[limber wedge]

Yes 100% (the feeling when you make a git blame and its you)

[lusty galleon]

Commented on PR

(btw, thanks for everyone's work in here. I've been slowly deleting my make files and reworking my workflows to use bevy_cli and it has been a joy.)

[limber wedge]

We are so lucky to have you as our dedicated tester ^^

[lusty galleon]

If not doing wasm-opt by default a message like "wasm-opt not enabled, skipping." would be nice.

[near mist]

yeah, i remember wasm-opt being pretty critical to making my "that's a LOT of entities!" themed jam game run smoothly on web

[twilit dew]

hhh@hhh-fedora ~/g/avian (ci)> bevy lint
error: process didn't exit successfully: `/home/hhh/.cargo/bin/sccache /home/hhh/.cargo/bin/bevy_lint_driver /home/hhh/.rustup/toolchains/nightly-2025-04-03-x86_64-unknown-linux-gnu/bin/rustc -vV` (exit status: 2)
--- stderr
sccache: error: failed to execute compile
sccache: caused by: Compiler not supported: "error: expected one of `!` or `[`, found keyword `if`\n --> /tmp/sccacheypo65e/testfile.c:2:2\n  |\n2 | #if defined(__NVCC__) && defined(__NVCOMPILER)\n  |  ^^ expected one of `!` or `[`\n\nerror: aborting due to 1 previous error\n\n"

Check failed: exit status: 101.
Error: command `/home/hhh/.cargo/bin/bevy_lint ` exited with status code exit status: 101

Is bevy lint not compatible with sccache?

seems not 👀

Disabled sccache, now I get

error: failed to find a `codegen-backends` folder in the sysroot candidates:
       * /home/hhh/.rustup/toolchains/nightly-2025-04-03-x86_64-unknown-linux-gnu
       * /home/hhh/.rustup/toolchains/nightly-2025-04-03-x86_64-unknown-linux-gnu

error: could not compile `avian_derive` (lib) due to 1 previous error
warning: build failed, waiting for other jobs to finish...
error: could not compile `avian_derive` (lib) due to 1 previous error
Check failed: exit status: 101.
Error: command `/home/hhh/.cargo/bin/bevy_lint ` exited with status code exit status: 101

I used

rustup toolchain install nightly-2025-04-03 --component rustc-dev --component llvm-tools-preview
rustup run nightly-2025-04-03 cargo install  --git https://github.com/TheBevyFlock/bevy_cli.git  --locked bevy_lint

to get the linter on the current main

For context, this is me trying out bevy lint in avian

[limber wedge]

did you try a cargo clean?

[twilit dew]

nope

[near mist]

i noticed bevy CLI checks if a program is installed by trying to run it as a command with --version

would it be better to use something like which?

or does that not work because it assumes the user is on linux

[limber wedge]

This does not work under windows iirc so yea

and imo we don't offer to install that many packages that its a problem yet. I think we can refactor that if we encounter a program that does not have a --version command (or an alternative version command)

[sturdy tapir]

This is the standard way to check for programs tbh

[near mist]

ic, fair enough

[twilit dew]

Same error after cargo clean

can you run bevy lint on https://github.com/Jondolf/avian ?

[limber wedge]

yes this works for me

❯ cargo uninstall bevy_lint
    Removing .cargo/bin/bevy_lint
    Removing .cargo/bin/bevy_lint_driver

installing linter

❯ rustup toolchain install nightly-2025-04-03 --component rustc-dev --component llvm-tools-preview
rustup run nightly-2025-04-03 cargo install  --git https://github.com/TheBevyFlock/bevy_cli.git  --locked bevy_lint

Running bevy_lint on avian main branch:

avian on  main via 🦀 v1.86.0
❯ bevy_lint
warning: unconventional type name for a `SystemSet`
  --> crates/avian2d/../../src/collision/broad_phase.rs:80:10
   |
80 | pub enum BroadPhaseSet {
   |          ^^^^^^^^^^^^^ help: rename `BroadPhaseSet`: `BroadPhaseSystems`
   |
note: structures that implement `SystemSet` should end in `Systems`
  --> crates/avian2d/../../src/collision/broad_phase.rs:80:10
   |
80 | pub enum BroadPhaseSet {
   |          ^^^^^^^^^^^^^
note: `SystemSet` implemented here
  --> crates/avian2d/../../src/collision/broad_phase.rs:79:10
   |
79 | #[derive(SystemSet, Clone, Copy, Debug, PartialEq, Eq, Hash)]
   |          ^^^^^^^^^
   = note: `#[warn(bevy::unconventional_naming)]` on by default
   = note: this warning originates in the derive macro `SystemSet` (in Nightly builds, run with -Z macro-backtrace for more info)

warning: unconventional type name for a `SystemSet```

[twilit dew]

huh, interesting

let me enter the same commands

[limber wedge]

but im on macos i can test on linux tomorrow at work

[twilit dew]

still same :/

[twilit dew]

I'd be glad, thanks 🙂

[limber wedge]

and maybe create an issue and then we can take a look at it after releasing 0,1,0 of the cli

[twilit dew]

done

[foggy basin]

I can't reproduce, on Linux (Pop!_OS) with the latest CLI from main

Did you try rustup update already?

[twilit dew]

Hmm, then maybe my ~/.cargo/config.toml is the issue

[twilit dew]

did not

[twilit dew]

(see https://github.com/TheBevyFlock/bevy_cli/issues/428)

[twilit dew]

Though that shouldn't help, right? It's using a fixed toolchain version

Unless I misunderstand something

[foggy basin]

Yea it's a shot in the dark :P

[twilit dew]

Same issue after rustup update

[foggy basin]

I wouldn't be surprised if cranlift is the issue here

[twilit dew]

fair point, let's try without it

Ding ding ding!

Looks like that was it

[foggy basin]

The linter infrastructure probably abuses rust internals too much :D
That's a shame though, especially because cranelift is probably a big compile time win and we advocate for short compiles with Bevy

[twilit dew]

Oh wait, I used rustup component add rustc-codegen-cranelift-preview --toolchain nightly

maybe I should fix the toolchain!

[foggy basin]

If we can't support cranelift with the linter, we should at least detect this situation and properly inform the user in the short-mid term.
I think that can wait for after 0.1 though :)

[twilit dew]

rustup component add rustc-codegen-cranelift-preview --toolchain nightly-2025-04-03 works 🎉

[foggy basin]

That's awesome, I actually didn't expect cranelift to be able to work with that!

[limber wedge]

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

[twilit dew]

oh yay!

BTW, I just discovered something neat

cranelift cannot compile wasm stuff (at least not out of the box)

But because bevy run web passes the web profile, I can add this to my ~/.cargo/config.toml:

[profile.web]
codegen-backend = "llvm"

[near mist]

and web-release should inherit from web, right?

although i suppose you'd have cranelift disabled for release builds anyways

[twilit dew]

yep

[rocky oxide]

bjorn3 hangs out in the Bevy community sometimes 🙂 Be sure to report problems to cranelift please

[foggy basin]

Bugfix for bevy run web when you use a custom web folder: https://github.com/TheBevyFlock/bevy_cli/pull/435

[limber wedge]

bug fix directly from RustWeek 🚲

[foggy basin]

Next week I'll be on vacation with limited access to my laptop, so gotta get in those fixes in time for the Bevy jam!

[limber wedge]

oh nice! where are you going?

[foggy basin]

Just visiting family :)

[foggy basin]

I'm also bothering all bevy contributors at the conference (there are a lot of them) to try out the CLI, so hopefully we will get some more feedback in soon-ish!

[limber wedge]

lovely hope you can relax and enjoy the time then 💚

[limber wedge]

nice you are our representative ^^

im a bit sad if i just planned better i could have come too its not that far from Switzerland

[foggy basin]

There were quite a few questions about the linter actually, how it works internally.
I'm the least qualified from this working group to answer that so I hope I didn't give out false information lol

[foggy basin]

Next year!

[limber wedge]

from none bevy folks too?

[foggy basin]

I think it was just from bevy, but honestly not entirely sure anymore, too many faces in that short time haha

[limber wedge]

ahah yea no worries thanks a lot for doing the work and gather feedback!!

[foggy basin]

Thanks for implementing and reviewing so much stuff I get to talk about lol

Next year we gotta get you and @pale viper here as well, maybe even @twilit dew and @near mist.
Bevy tooling ftw!

[pale viper]

Please! That sounds really fun!

Have a great vacation, @limber wedge and I will hold down the fort while you're gone

Speaking of which, @limber wedge do you want us to call you by a nickname or something? @foggy basin is "Tim", but it feels silly calling you "Squishy" 😅

[limber wedge]

i don't really mind either my real name is David so feel free to call me by that ^^

[pale viper]

David it is! "BD" or "Bryan" work for me :)

[twilit dew]

In my mind, you’re Albrecht because of GitHub 😄

[rocky oxide]

FYI I was chatting with wgpu folks today about this tool 🙂 A Bevy VsCode extension came up, and I explained that my vision for that was to have it be a thin layer that just calls into the bevy_cli for various things

Which makes it much easier to share things with the editor, or other IDEs

[limber wedge]

Yes please! Its always so sad when cool tools are only existing as vscode plugins

[foggy basin]

May 18-22 2026 @pale viper @limber wedge @twilit dew @near mist Mark the date, maybe we can all meet up!

[limber wedge]

I tried to start a Configuration section for the cli: https://github.com/TheBevyFlock/bevy_cli/pull/438 i think this is very important so please be very critical

[twilit dew]

done

@foggy basin @pale viper not directly related to the CLI, per se, but a nice member of the community just offered to donate a pretty decent machine to Bevy in some fashion.
I was thinking maybe this could be used as a community CI runner for projects that want to have faster (Linux) builds for their Bevy things. Thoughts on feasibility?

Pinging you because you two are literal CI wizards in my mind 🙂

[fresh forge]

I was trying to generate a file from the 2d template but it skipped all the files and gave me this error, any ideas?

https://discord.com/channels/691052431525675048/1372507436296175686

[near mist]

i can reproduce that. it's probably due to a recent change to that file, i'll take a look

[fresh forge]

Thank you!

[near mist]

can you try again?

[fresh forge]

yess it worked!

thank you!

[pale viper]

That's really generous, but it can be tricky to do! A community CI runner basically lets anyone run untrusted code on that computer, so it needs to be properly sandboxed and crash-tolerant

Github Actions supports custom runners, so it shouldn't be difficult to setup for a repository / org. Do you think the machine would be available to just bevyengine / TheBevyFlock, or would it be accessible to anyone working on a Bevy-related project?

[twilit dew]

Unfortunately I know very little about those things

[foggy basin]

Otherwise I assume the Bevy foundation could use it for things
I heard they are planning to buy a machine (or have already done it), you could reach out to François

[rotund condor]

Hey, chiming in 😄 I forwarded this discussion to #community

[rocky oxide]

Lint idea: check if the type_complexity idea

[limber wedge]

Can you elaborate? I can create a issue afterwards

[rocky oxide]

Also lang team is interested in first class support for custom lints but not sure on a design

[rocky oxide]

Having the type_complexity lint on is a mistake in Bevy projects

We should detect if it's on and complain

[limber wedge]

Oh ye makes sense!

[limber wedge]

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

[rocky oxide]

Thanks!

[foggy basin]

Another lint idea from François, based on problems people ran into in the workshop: detect if the items inside the children! macro are different components and warn in that case. That will put them on different entities, but in the workshop people wanted them on the same entity.
To fix this the user would have to put them in a tuple

It might have false positives though

[rocky oxide]

Another lint suggestion: enum inside of a state enum

They just want substates but don't know how to use them

[exotic geyser]

would be interesting to have this as a lint

I guess the linter would check for uses of the component in a query on a system that is added by a plugin, either in the project crate or dependencies

[pale viper]

That seems very heuristic-y, I feel like there'd be a lot of false positives with how plugins are currently setup

Maybe if there was some way to associate some components with a plugin in the plugin's trait impl? That seems a lot more useful

I definitely see where you're coming from, though! We need a better way to associate plugins, components, and resources together

[sturdy tapir]

The actually solution is two lints imo

unused component that lints for components that are not in any queries or spawns or bsn
And
unused plugin that lints for plugins not added anywhere but are defined.

These two achieve the same goal while being very simple and more controllable

This also builds off the unused struct/fn/etc lints common to rust

[twilit dew]

If you use pub(crate) instead of pub, clippy will already take care of the first one

Unless I'm misunderstanding you

[sturdy tapir]

No one really cares about pub rules when you're the end product user/j
But no I'm more getting at how a component not used isn't registered and effectively doesn't exist. (Which apparently will harm bsn loading)
Would like for a lint that ensure components get registered either via register_type or via query/spawn use

[twilit dew]

I still don't see how that's different from letting clippy lint it as unusued

[twilit dew]

Also, I really wish there was a way for me to tell Rust "plz treat all pubs as pub(crate) so that my linter works correctly, thanks"

[sturdy tapir]

Ecs world doesn't know struct A until its either used in a spawn, a query, or registered manually.

When bsn rolls around, if a bsn file uses the component, it isn't registered, so it can't figure out what struct the bsn is referring to.

Ran into this the other day with editor stuff

The unused clippy lint goes away to eagerly compared to what bevy needs for unused components

[twilit dew]

Do you have an example where an unused pub(crate) would not be linted by clippy, but would be linted by a hypothetical CLI lint?

Maybe I'm just being obtuse, sorry 😅

[sturdy tapir]

Idk how else to explain it.
Reread what the original problem is
I'm talking bout splitting that desired lint into two which indirectly solves the issue.

[twilit dew]

Rereading it, I still don't get how that first lint is necessary beyond what clippy already offers.
But I trust you that there is a good reason and that I'm just not seeing it right now 🙂 Probably because I have not run into the problem of using not-yet-registered components yet, so I'm probably just too much out of the loop to get it

[twilit dew]

@sturdy tapir I just realized my message might sound a bit passive-aggressive, hope that is not how it came through. I legit am probably being just a bit dumb in this point 😅

[foggy basin]

On main I'm now getting errors running the examples on the web, with

bevy run --example=breakout web

In the console:

Uncaught TypeError: The specifier “env” was a bare specifier, but was not remapped to anything. Relative module specifiers must start with “./”, “../” or “/”.

It seems to pull in an env package in the first line of the JS bindings:

import * as __wbg_star0 from 'env';

Did anyone run into that yet?

It might be a CLI issue, but it still works on bevy_new_2d

[limber wedge]

Can try later today. What is the verbose output of the cli?

[foggy basin]

Ah the error is not when building, it's in the browser console when running.
See https://github.com/bevyengine/bevy/issues/19225
I can get the verbose output later :)

[trail shale]

Bevy builds fine in CI in wasm 🙂

https://github.com/bevyengine/bevy/actions/runs/15061594769/job/42337580823

[foggy basin]

It appears to be a problem with nightly Rust. I'll try creating a bug report on their repo

[foggy basin]

@pale viper @limber wedge does bevy_lint work in a similar way as dylint? I keep getting the same question and can't answer it

[limber wedge]

I dont really know dylint so take this with a grain of salt until BD wakes up😂

I think under the hood they work the same way they both are a rustc driver that registers additional lints but they have different goals (beyond bevy_lint obviously being a bevy linter ^^)
Iirc BD mentioned that he started with dylint originally when creating bevy_lint but wanted bevy_lint to be available as a standalone tool while dylint is more like a collection of lints that you can dynamically enable on your project

[pale viper]

It is similar to dylint, a lint written for dylint can be easily ported to bevy_lint

dylint, however, supports loading custom lints. All of bevy_lint's lints are predefined and cannot be extended without recompiling the linter

This makes bevy_lint simpler than dylint, which is why I usually compare it with Clippy (which is much more similar)

[foggy basin]

Thanks to you both!
It hooks directly into rustc internals, right?
What was the reason to not use dylint again? Simplifying our setup?

[pale viper]

It hooks directly into rustc internals, right?
Yup!

What was the reason to not use dylint again? Simplifying our setup?
Exactly, dylint was overkill and harder to ship

Also, @foggy basin @limber wedge what are your thoughts on the current state of issue labels and types? Is there anything we're missing / don't need?

I feel like we have a lot of A- area labels that may need to be rethought

Also I noticed Tim has been marking issues with their type, should we start doing that as well?

[limber wedge]

I dont have a strong opinion. Personally i prefer the cli/ linter (compared to only using the subcommand label) label so its easy to spot the difference especially for potential new contributors.

[limber wedge]

Im open to this but then we should either use the label or the type otherwise it feels a bit repetitive

[foggy basin]

Yea the duplication is a problem
I mostly like how it displays in the github, but I also have no problem switching back to labels

[foggy basin]

What do you have in mind?

[near mist]

bevy cli should probably support customizing the arguments passed to wasm-opt for web release builds

created an issue: https://github.com/TheBevyFlock/bevy_cli/issues/442

[trail shale]

the dioxus-cli does a lot of nice things 👀

(and works with Bevy 😄 )

[limber wedge]

they do a lot of cool things in general

[limber wedge]

do we have any other outstanding open issues that need to go into 0.1.0 besides the two open pr's? (#436,#424) @foggy basin @pale viper

[foggy basin]

Yes, I think in addition to supporting a boolean in the config we should also accept a string array where you can then define custom settings. For wasm-bindgen we might want this as well.

[foggy basin]

I can't think of anything critical on the top of my head.
A couple of people tested it at RustWeek and they all had ideas for things to improve, but I think nothing that should block the 0.1 release.

I think one thing we should think about is to have a pre-release, then we could already test the release process and cargo binstall

[pale viper]

I merged #424 and addressed your review of #436, so we should be really close!

And I'm not sure how much benefit a release candidate / prerelease would have, since we've already had a lot of field testing and we need to release v0.1.0 anyways by the end of the month

Personally I'm leaning towards just pulling the trigger and releasing v0.1.0 in the next day or so. We can always release a v0.1.1 if necessary :)

I do want to write up a release checklist, but it doesn't necessarily need to be done before we release

[limber wedge]

Nice! Sorry didn’t have time today but will look tomorrow!

[limber wedge]

Im good with either. We also still need a maintainer‘s approval so this probably also needs some time

[foggy basin]

@trail shale briefly tested the CI on one day of the rustweek, but we didn't have time for a thorough review.
Not sure if that counts as approval already :D

[sturdy tapir]

can someone familiar with cargo's deep settings give a rough list of the most important settings someone would want?
ive never dived into cargo customization

[near mist]

like settings you'd put anywhere in Cargo.toml? or a particular section?

[sturdy tapir]

global cargo settings

[near mist]

ah so like description, author, etc?

[sturdy tapir]

the launcher will help manage cargo/rustup/bevy_cli

[sturdy tapir]

no like cargos settings that apply to all projects made etc

[near mist]

can you give one example of this?

[foggy basin]

You mean the settings for fast compile times?

[sturdy tapir]

uhh path for cargo to save package downloads
stuff like that

[near mist]

ic, so like the type of thing you might put in ~/.cargo/config.toml

[sturdy tapir]

i guess

just whats most important to users

[near mist]

there are things like setting up mold linker, nightly arguments like -Zshare-generics=y and -Zthreads=0, cranelift, etc. to speed up compile times

also setting up sccache requires certain options

[near mist]

some users direct all their build artifacts between different projects to a single shared target/ directory

[sturdy tapir]

yea this is type of stuff im thinking of that dev teams will appreciate

the launcher affords us an opportunity to offload many settings so the editor is just managing itself and the current project

[near mist]

there are also non-cargo things like rustfmt.toml settings

[sturdy tapir]

yea

[near mist]

i'm wondering logistically, this is meant to be a single place to edit these settings and then it applies to all your existing and future projects?

unless they explicitly override

[sturdy tapir]

pretty much

[near mist]

suppose you create a new project from a template which comes with a rustfmt.toml, would that be considered a per-project override? what if it only sets options A, B, and C, while the launcher sets B, C, and D?

do you lose option D or do they get merged

[sturdy tapir]

is rustfmt.toml local to projects or is it like cargo and lives in a system config?

[near mist]

it's local to projects, i'm not sure if there's a global version as well

[sturdy tapir]

the expected behavior would prob be merge

[foggy basin]

One thing we would also need to be careful about is that these settings would apply to all Rust projects, not only the Bevy ones. Might not be a problem, but could be unexpected

[near mist]

that depends on how/where the settings are saved. if the launcher modifies the user's global ~/.cargo/config.toml, then yeah

it sounds like we'd want an additional layer in between the user's global settings and each project's local settings, for the launcher's "global" settings

but i'm not sure if tools like cargo, rustfmt, etc. can be instructed to check another layer of configs?

if so that would be perfect

well bevy CLI might be able to shim that layer somehow

[sturdy tapir]

seems like a communication problem tbh
but yea id perfer if it could only effect bevy projects

[foggy basin]

Yes, there is the --config argument you can pass to cargo. You can either provide toml strings directly or a path to a config file if I remember correctly

[sturdy tapir]

that works great

[near mist]

i see. and where does that fit layer-wise, between user and project, or does it override project settings?

my assumption is the latter

[foggy basin]

We already use --config in the CLI go set up the default web profiles.

My guess is that it overrides all settings because CLI arguments usually evaluate last. Bug in theory you can provide the flag multiple times and it will be merged from left to right

[near mist]

hm so you could do like --config <launcher> --config <project>?

[foggy basin]

Before I provide wrong information, here's the reference:
https://doc.rust-lang.org/cargo/reference/config.html#command-line-overrides

[near mist]

The --config option may be specified multiple times, in which case the values are merged in left-to-right order, using the same merging logic that is used when multiple configuration files apply. Configuration values specified this way take precedence over environment variables, which take precedence over configuration files.

sounds good

then the question is whether other tools with settings (e.g. rustfmt) support something similar

~$ rustfmt --config-path rustfmt.toml --config-path b/rustfmt.toml
Option 'config-path' given more than once

there is a global config file for rustfmt: ~/.config/rustfmt/rustfmt.toml (see https://github.com/rust-lang/rustfmt/blob/master/Configurations.md)

[sturdy tapir]

hmm i guess we can make it per project default?

so launcher settings of rustfmt get dropped in at project creation time

[near mist]

i guess that doesn't sound like that bad of a UX as long as it's understood

my question would be about merging the launcher's settings with a template's existing rustfmt.toml on creation

vs replacing

[foggy basin]

We can also take one step at a time.
From what I have seen, custom rustfmt configuration is a lot less common than the compile settings.
I also think rustfmt configuration should probably be committed to git while in my (perhaps controversial) opinion the compile settings should not

[near mist]

yeah, changing a project's rustfmt settings means its formatting will be "wrong" until you run rustfmt again, which creates a git diff that you have to commit

[sturdy tapir]

templates can define them?

[near mist]

yep

bevy_new_2d comes with a decent amount of config files actually

[sturdy tapir]

true might be something to just ignore till people ask

would like atleast cargo config

what settings do bevy_cli have?

[near mist]

rustfmt.toml, .editorconfig, Cargo.toml, Cargo.lock, clippy.toml, .gitignore, .vscode/, .idea/, and .cargo/config_fast_builds.toml but that last one is not enabled until you rename it

[foggy basin]

I never noticed the rustfmt one, what does it change?

[near mist]

oh my bad

bevy_new_2d actually doesn't include a rustfmt.toml 😄

so it uses the default rustfmt options (as it should, even if i don't personally agree with all the defaults)

(here's the rustfmt.toml i personally use: https://github.com/benfrankel/pyri_new_jam/blob/main/rustfmt.toml)

[whole iris]

Does the CLI use trunk under the hood to build for web?

[limber wedge]

No we do not

[pale viper]

Cargo searches all parent directories for config.toml. If you put all Bevy projects within a specific folder, you can set default Cargo settings only for those projects :)

https://doc.rust-lang.org/cargo/reference/config.html#hierarchical-structure

[whole iris]

I get this:

lightyear/examples/simple_box on  bevy-main-refactor [$!?] is 📦 v0.1.0 via 🦀 v1.86.0
❯ bevy run web
error: There are multiple binaries available, try specifying one with --bin or define `default_run` in the Cargo.toml

lightyear/examples/simple_box on  bevy-main-refactor [$!?] is 📦 v0.1.0 via 🦀 v1.86.0
❯ bevy run web --bin main --open
error: unexpected argument '--bin' found

I only have one binary in my package

[pale viper]

Could you run bevy run web --verbose and send the command it logs? A link to the source code would also be awesome :)

[limber wedge]

Yes or the Cargo.toml if the repo is not public. for the latter error the command should be: bevy run --bin <bin-name> web --open

[whole iris]

Source coed is here: https://github.com/cBournhonesque/lightyear/tree/bevy-main-refactor/examples/simple_box

bevy run --bin simple_box web --open works

but normally i don't need to specify the name of the package

Another thing, are the rustflags in my .cargo/config.toml respected if i use bevy cli?
I have

[target.wasm32-unknown-unknown]
rustflags = ["--cfg", 'getrandom_backend="wasm_js"']

in them but i still got an error.

Running manually with RUSTFLAGS='--cfg getrandom_backend="wasm_js"' bevy run --bin simple_box web --open worked

Let me know if i should open an issue

[limber wedge]

I can take a look in about 1h rustflags from .cargo/config.toml should still work but you could also put them under the cli‘s config like in this example: https://thebevyflock.github.io/bevy_cli/cli/configuration.html#example

[foggy basin]

We essentially have to re-implement the binary resolution algorithm that cargo uses, so there currently might be slight differences in behavior. We will try to fix those though!

I think in this case what's happening is that we always search for binaries in the whole workspace, even though you are currently in the folder of a specific package.

Feel free to create an issue for this!

[whole iris]

this worked! will open an issue

[limber wedge]

not sure if you have uncommitted changes but i dont get to build this branch :( but i see that the .cargo settings do get picked up by the bevy_cli

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"' --bin simple_box --profile web --target wasm32-unknown-unknown
or
bevy build --bin simple_box web
result in the same compile error message when i add this to the .cargo/settings.toml: rustflags = ["--cfg", "getrandom_backend=\"wasm_js\""]. Without these rustflags both result in:

error: The wasm32-unknown-unknown targets are not supported by default; you may need to enable the "wasm_js" configuration flag. Note that enabling the wasm_js feature flag alone is insufficient. For more information see: https://docs.rs/getrandom/0.3.3/#webassembly-support

[whole iris]

This suggests that the settings.toml flags don't get picked up, no?

It works if I add them to the cargo.toml as you suggested above

[twilit dew]

what is a settings.toml? 👀

[limber wedge]

no since if the flag is missing the error is "The wasm32-unknown-unknown targets are not supported by default; you may need to enable the "wasm_js" configuration flag" but if the flag is present the errors are compile errors like rs error[E0277]: the `?` operator can only be applied to values that implement `Try` --> lightyear_webtransport/src/client.rs:81:29 | 81 | Err(err) => WebTransportError::Certificate( | _____________________________^ 82 | | "Failed to read certificate hash from string: {err:?}".to_string(), 83 | | )?, | |__________________^ the `?` operator cannot be applied to type `client::WebTransportError` | = help: the trait `Try` is not implemented for `client::WebTransportError so the .cargo/config.toml is picked up imo

[pale viper]

@limber wedge if you're still around, I'd appreciate you also reviewing https://github.com/TheBevyFlock/bevy_cli/pull/446

Turns out I broke the website twice haha

[limber wedge]

hahaha third time's a charm

sorry didn't wanna jinx you ^^

[pale viper]

🫠 🫠 🫠

One more PR it is!

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

[limber wedge]

[pale viper]

[limber wedge]

can you believe it? @pale viper

[pale viper]

And there was much rejoicing :D

[pale viper]

Note: I've made a few small changes to our labels that should hopefully make them easier to use

• A-CI is now A-Build-System to reduce confusion with A-CLI
• Removed A-Asset-Processing, since it's not yet a feature of the CLI
• Added A-Meta for discussions on triage and other processes
• Changed C-Breaking-Change to M-Needs-Migration-Guide
• Added O-Linux, O-Windows, and O-MacOS for platform-specific issues
• Added P-Regression for things that used to work but are now broken (I'm looking at you, website T.T)
• Fixed all the label colors to match the Bevy engine's colors

[twilit dew]

Could the CLI always pass the annoying getrandom rustflag to web builds? Just found out that my local Wasm builds do not use the nightly flags speedup flags because I included the following in my Cargo.toml

[package.metadata.bevy_cli.web]
rustflags = ["--cfg", "getrandom_backend=\"wasm_js\""]

see https://github.com/TheBevyFlock/bevy_cli/issues/444#issuecomment-2891804412

[twilit dew]

related: I'll be using dx serve --hot-patch instead of bevy run from now on because of hotpatching: #crates message

Don't know if wrapping that should also be in-scope for the Bevy CLI

[near mist]

bevy run --hot-patch 🥺

[twilit dew]

No clue if dx even comes as a library

Ah wait, we download a CLI already for wasm-opt

so we could just download that as well

[twilit dew]

dx serve accepts very different arguments than cargo run unfortunately

[rocky oxide]

This is my ideal end user experience

[twilit dew]

Opened an issue: https://github.com/TheBevyFlock/bevy_cli/issues/451

[foggy basin]

For stuff like this I also want a user-wide config

[near mist]

some bevy cli related discussion here: #1374187654425481266 message

[limber wedge]

I would like to cut 0.1.0 from the current main and not take more in thoughts? Then we can get a maintainer to review and release @foggy basin @pale viper

And afterwards we add a milestone for 0.2.0

[molten merlin]

(if it impacts the decision at all I'm planning to try to release videos for the cli and the associated templates a couple days before the jam. so having a release would be real nice)

[near mist]

the jam starts on may 31st for context. i should try to get a pause menu for the template in soon then

[rocky oxide]

FYI @gusty hawk there's a fair bit of Rust project interest in better support for custom linters

I would expect progress on the order of a couple of years of course

But worth keeping in the back of your head

[gusty hawk]

https://github.com/DioxusLabs/dioxus/blob/main/packages/cli/src/cli/target.rs

we also have a ‘dx run’ command

[pale viper]

Totally! I made a minor update to https://github.com/TheBevyFlock/bevy_cli/pull/447, so I'd like a second review / re-review there, then we can open the v0.1.0 release PR

@foggy basin since you've been spearheading the CLI, do you want to be the person writing the changelog and actually cutting the release?

[foggy basin]

I'm on vacation this week and have limited access to my PC, so Im not sure when I'll have the time :(
But I'm fully on board with releasing, I think we are in a great state for a first release!

[trail shale]

I'll do a quick review in the next few days, and the idea would be to do a release 0.1.0-alpha.1

[pale viper]

Have a good vacation! In that case, I or @limber wedge will open the PR. What day do you get back from vacation? I'd like you to be around when we do the release

[pale viper]

What's your reason behind making an alpha release and not a regular v0.1.0?

[foggy basin]

I will be back on May 29.
I can do some light work on the phone, so I might be able to review stuff before that. I just probably won't be able to implement or write larger things myself :)

[trail shale]

it's not an official Bevy project, so if it's called bevy it should be marked as an alpha until it has been reviewed and brought back to the main org

[pale viper]

Unfortunately that's not how the linter's releases have gone, they're normal v0.1.0, v0.2.0, and v0.3.0

I originally proposed making linter releases -alpha, but it was turned down as needless

1. We're not publishing to crates.io, where the linter and CLI crate names are reserved by Cart
2. There are several warnings saying this is an unofficial community project, not to mention its source and website are through TheBevyFlock

I'd much prefer we release a v0.1.0, or at least a release candidate and then a v0.1.0, as that's how the linter operates

[twilit dew]

(I also find it a bit amusing to use a prerelease (0.x.x) on a prerelease (-alpha) for something that is this usable already 😅)

[sturdy tapir]

Not to argue but that logic seems a little flawed when I look at the community?
Almost all 3rd party crates for bevy start with bevy?
I'm with BD they make it very clear they aren't official rn

[near mist]

the main difference is the binary itself uses the name bevy

[pale viper]

<@&1064695155975803020> the PR for the v0.1.0 release of bevy_cli is open at https://github.com/TheBevyFlock/bevy_cli/pull/454! Just like the linter, the CLI requires an approval from at least one Bevy maintainer before it can be published. Please try out the CLI and leave your thoughts on the PR, thank you! :D

[pale viper]

@foggy basin @limber wedge if you could look through the changelog in that PR and make sure I'm not missing anything, that would also be great!

[analog fern]

Yeah this is the main sticking point. Currently this project is operating under the exact same branding that we will use for the official cli:

1. bevy for the binary name
2. bevy_cli for the crate / repo name

The reason we don't want to publish the crate yet is that it hasn't gone through our normal processes / extensive review from leadership. This is fundamentally a "branding issue". We don't want something to seem official that hasn't been fully vetted / isn't "under the bevy umbrella".

The current naming scheme has already compromised that. It is very hard to distinguish between "the future official bevy_cli" and "the unofficial Bevy Flock cli", both when talking about the projects generally and from a versioning perspective. There will be ambiguity between bevy_cli v0.1.0 (unofficial git release) and bevy_cli v0.1.0 (official crate release).

This "blurring of the lines" feels intentional: clearly this working group wants this to be official eventually. I'm on board for this strategy / I'm pretty happy with how things are progressing / how this is being run. But I think something needs to give. Either:

1. We change the branding to something unambiguous with the official cli (ex: bevy_flock_cli, bcli, etc). Ditto for bevy_lint. This would fully resolve all confusion, and allow Bevy Flock devs to version in whatever way they want and publish to crates.io.
2. We adopt alpha terminology and versioning until it is upstreamed and under the Bevy umbrella. We continue to refrain from publishing to crates.io until it is upstreamed and under the Bevy umbrella.

If I had a time machine, I would have preferred to do (1) from the beginning to avoid confusion entirely (and it is also on me for not using a stronger hand here earlier). But I do also concede that we are now already in a gnarly middle ground state, so the best path forward is less clear. I'm curious what you all think!

@pale viper

[twilit dew]

just asking for future reference, would variant 1) also encompass using a different binary name like bevy_flock? Or is it fine to use the binary name bevy when the repo / crate name already convey the unofficial-ness

[analog fern]

Not throwing shade, but this is the kind of thing that I see as problematic / confusing for our users:
#jam message

From my perspective there is no THE Bevy CLI

(yet)

I am highly confident that this project will ultimately become it, but (for the same reason I'm holding the line for THE Bevy Editor vs bevy editor prototypes), I think this distinction is important

[twilit dew]

fair enough, my bad 🙂

[analog fern]

No worries. Not assigning blame here. The way the branding is currently set up makes the distinction essentially impossible, and its really just my fault for not addressing this earlier.

[twilit dew]

If you don't mind, could you comment on which of these are okay from a branding standpoint?

• "The Bevy CLI prototype"
• "The Bevy Flock CLI"
• "A Bevy CLI"
• "The Bevy WG CLI"
• "Our CLI"

[analog fern]

All of those seem fine to me. Although "A Bevy CLI" would be awkward and potentially ambiguous in certain sentences

I'm also cool with "Bevy CLI alpha"

As this is an official working group

[twilit dew]

Got it 🙂 Mainly asking so that I know how to refer to future prototypes from WGs correctly

Thanks for clarifying!

[analog fern]

Notably I'm cool with "alpha" as we've already been operating in a middle ground state and the linter is reasonably far along ... I probably wouldn't have embraced that from the get-go. And I wouldn't support "The Bevy Editor alpha" for the current prototypes as we aren't close to being "there" yet

[pale viper]

Your arguments make sense! I do agree we've been blurring the line, since our official working group status gives us some authority to do so, but I also see how it's too close to appearing official for your liking

I personally like using "The Bevy CLI (Alpha)" and "The Bevy Linter (Alpha)" for titles, out of the options you and Jan listed. Both the CLI and linter are relatively polished products (compared to the editor), but the term "Alpha" gives users enough hesitance that it should convey the right message

[twilit dew]

@analog fern could you comment on this? 🙂

[rocky oxide]

This would be my preference 🙂

I think it's much clearer

[pale viper]

I'm cool to change the binary name of the CLI, although I don't have too many good ideas for what it may be. (@snow linden you're good at naming things, maybe you could help?)

Would the crate names also need to be changed, or are they fine as bevy_cli and bevy_lint?

[rocky oxide]

FWIW, part of the reason I care about this being "clearly unofficial / unfinished" right now is to allow y'all to experiment and iterate more quickly, without the level of polish and oversight that the alternative implies 🙂

It's not "we don't like this / don't want to adopt it", it's "that level of officialness implies a level of polish that will slow this down"

[rocky oxide]

If this was my project I would swap to consistent branding across all of those to reduce confusion

bevy_flock for all of them would be my first choice of name

[pale viper]

Yup! Totally understand, and it's been nice working quickly :)

[pale viper]

Something like bevy_flock_cli and bevy_flock_lint, then the compiled CLI binary is just named bevy_flock?

[rocky oxide]

Yeah!

[lusty galleon]

flock run feels nice

[pale viper]

Oooo I do like that

Using that, I'm thinking:
bevy_flock_cli crate -> flock binary
bevy_flock_lint crate -> flock_lint and flock_link_driver binary

[foggy basin]

What would be the envisioned process to transition from a prototype/community project to the "official" CLI?
Because I think from the side of our working group, we would be ready to start this process now.
Of course there are still things that are missing, but I think it's good enough for an initial release

[pale viper]

I was going to bring this up as well, I’d like to hear the tentative plan for how and when we’d be ready to be made official

[rocky oxide]

From my end, I'd like to see:

1. Polished documentation
2. Positive user feedback from the jam
3. Relatively clean code base
4. Technical foundations that we're all happy with
5. Migration strategy for open issues
6. Release notes
7. Experimental pass with the linter on the Bevy repo (integration into CI can come once upstreamed)
8. Plan for support of previous Bevy versions ("we don't support that" is fine)

[foggy basin]

The way I understood it, upstreaming the CLI was an explicit goal of the working group. If I remember correctly, the repo for this was also created by maintainers.
To ensure that the CLI aligns with the project vision, a maintainer review is a key part of our release process. The linter was ready earlier and has already been reviewed and each release PR approved, while the CLI took a bit longer and would have its initial release (and corresponding maintainer review) now.

We are always happy with changing things around if it doesn't align with the project vision! But that's why it's important to get "official" feedback now, because there is no point in developing a CLI that won't be upstreamed -- users shouldn't have to select between different tools for something foundational like this.

So my understanding was that we get this reviewed, make adjustments as necessary and then end the working group and get the project upstreamed

[limber wedge]

So if i understand this correctly the plan is:

1. release 0.1.0-alpha
   2 get feedback from the jam
2. in depth review from a maintainer
3. start upstream process as outlined by Alice

[pale viper]

That seems like the path of least resistance. We rebrand the docs to “The Bevy CLI (Alpha)” and make an initial release

We hold off rebranding the linter until after the CLI is released (likely just title changes to “The Bevy Linter (Alpha)”, since we cannot easily change the version numbers already released)

I played with around rebranding everything to “The Bevy Flock CLI”, but it required a significant amount of changes to the code and docs that I’d rather avoid

[pale viper]

@analog fern would you be happy with this plan? It’s the one we can implement the quickest (for the game jam) while still addressing your concerns

[pale viper]

I've updated https://github.com/TheBevyFlock/bevy_cli/pull/454 to use v0.1.0-alpha and include more "Alpha" and "prototype" terminology in the docs. Please let me know your thoughts :)

[rocky oxide]

Much more WARNING WARNING coded 😄

[twilit dew]

TIL there's a resolver v3 👀

[molten merlin]

it was a 2024 edition thing

[twilit dew]

oh, looks like it's implicit in 2024 anyways

[analog fern]

So my understanding was that we get this reviewed, make adjustments as necessary and then end the working group and get the project upstreamed

Yup that was my understanding as well!

And I'm definitely glad that we've been kept in the loop as things develop! However (at least for me) I've never done a review of the code, or more than a quick pass over some of the linter rules

[analog fern]

Yup I like this plan!

Thanks for being flexible!

[analog fern]

Looking back on the history, the repo name was definitely selected by maintainers 🙂

And I've certainly been aware of the name since the beginning / I'll reiterate that this is my fault for not stating this all sooner

[analog fern]

Hmm 0.1.0-alpha creates the question "what do we call the next alpha release". From my perspective, all alphas should be leading up to an official 0.1.0 release (including a crates.io release), so it seems like the versioning should be 0.1.0-alpha.1, 0.1.0-alpha.2, etc

In public communications, we could consider shortening those to "Bevy CLI Alpha 1", `Bevy CLI Alpha 2", etc

^ just mirrored this to the PR

[twilit dew]

Since the CLI also encompasses default templates, I want to point out that bevy_new_2d is also ready for reviews for upstreaming.
Or we keep the CLI pointing to TheBevyFlock for templates when it's done, that's also fine.

[rocky oxide]

Or we keep the CLI pointing to TheBevyFlock for templates when it's done, that's also fine.
This seems pretty good, at least until we're really pushing the templates

Nice to be able to keep experimenting and refining

[twilit dew]

Works for me, I was just a bit worried for a second that an upstreamed CLI would no longer point to the 2D template when using -t=2d🙂

[rocky oxide]

Yeah, I'll want to do a quality pass on it but I don't want to change that 🙂

[twilit dew]

thanks!

[pale viper]

Of course! I'm glad we could figure something out :)

[pale viper]

Yeah, I'd like to yeet bevy_github_ci_template at some point and switch to bevy_new_2d and bevy_new_minimal as the official ones

We can add support for searching the bevyengine org as well as TheBevyFlock for the shortcut as well, making migration easier

[near mist]

i think once we have a pause menu (soon), it'll be in a good place to be more stable

since it'll basically be feature complete

[rocky oxide]

I would actually like a "just CI" template at some point too

[near mist]

that's bevy_new_minimal 😄

[rocky oxide]

That's what I want for my projects for example

[rocky oxide]

Oh perfect lol

[near mist]

well if you accept .vscode/ etc. metadata files as well

although it doesn't have that yet but iirc it was considered in scope at the time

[rocky oxide]

Yeah I don't hate that

[twilit dew]

Strongly in favor of having those in the minimal template

[pale viper]

While I have your ear, thoughts on v0.1.0-alpha.0, v0.1.0-alpha.1, or v0.1.0-alpha for the first release of the CLI?

[near mist]

for now it's not there to avoid duplication with bevy_new_2d until we're confident they won't change much anymore

[twilit dew]

I'd just follow Bevy's schema and use -alpha.1

[pale viper]

If we're going to have multiple alpha.NUMBER releases, I'm leaning towards -alpha.0 or -alpha.1

[pale viper]

Good call

[twilit dew]

(since rc-1 also starts at 1)

You can be super unambiguous by calling it v0.1.0-first, which would allow any number to be matched above it per semver, as it sorts prereleases alphanumerically /j

[pale viper]

v0.1.0-first+SUPERCOOLMETADATATHATGETSIGNORED

[twilit dew]

Oh right I always forget about those 😄

+this_is_not_official_remember!

[pale viper]

I've always wanted to genuinely use metadata in the versions, but never found a reason

[twilit dew]

A friend once passed information to a CI pipeline with it

Because it had no better way to pass any data lol

I think it was an early version of Azure DevOps

[pale viper]

Oof that's crazy

I think there's some rustc crate that uses the version metadata for the commit hash

Oh yeah, it's rustc_apfloat!

[twilit dew]

hehe

[pale viper]

They append the LLVM commit hash to the version, like 0.2.2+llvm-462a31f5a5ab

[lusty galleon]

Would like to check out this CI template. The .workflows directory is empty after a bevy new -t minimal test though?

[pale viper]

Looks like there isn't any built-in CI, actually

[twilit dew]

FYI minimal is what is used by bevy new implicitly

[pale viper]

https://github.com/TheBevyFlock/bevy_new_minimal/blob/main/cargo-generate.toml: the workflow is ignored

[near mist]

ah, same story as the .vscode/, it's in scope though

but we've been making a lot of changes to the .github workflows in bevy_new_2d and it'd be a pain to duplicate every PR

[twilit dew]

Ah yeah I remember

We disabled it intentionally until stabilization I believe

[lusty galleon]

Will it be possible for folks to develop third party templates that are instantiable with the cli? I assume these two specific templates are sorta hardcoded now?

[near mist]

yes it's already possible!

[twilit dew]

Already is 😄

[near mist]

you can use --git

[pale viper]

You can do so already! It's -t https://github.com/Name/Template I believe

[near mist]

here's my personal template, migrated to bevy cli: https://github.com/benfrankel/pyri_new_jam

[pale viper]

Check out https://thebevyflock.github.io/bevy_cli/cli/scaffolding.html

[twilit dew]

Yeah even no --git needed

[near mist]

oh wait not --git my bad lol, it's still --template it just recognizes

[twilit dew]

All that bevy new -t foo does is implicitly prepend the bevy flock org 🙂

[pale viper]

Close, I think cargo-generate may use --git though?

[near mist]

yes i probably got it confused with cargo-generate. they support --branch, --rev, etc. as well

it seems bevy new only has --branch for now but i think i made an issue for that

[pale viper]

bevy new is just a frontend for cargo-generate, but I don't know how similar the user interfaces are

[pale viper]

There's an issue for that, though! :)

Anyways, I'm glad we got the CLI concerns figured out. As it's late where I am, I'm going to wait until tomorrow to address the changes in the PR and hit the merge button

Super exciting! :D

[near mist]

even -t name/template works as shorthand btw

[pale viper]

Oh sweet, we should document that!

[twilit dew]

oh wow that's neat!

[limber wedge]

Jan never sleeps

[twilit dew]

I really didn't sleep this night because I had to get up super early

[limber wedge]

Take care !😤 but i guess you you cant let go of the hot patching thing hahaha

[twilit dew]

it's just too exciting 😄

[near mist]

he's still reviewing my bevy_new_2d prs too

[pale viper]

Ok, I'm hitting the button for the release! No merging until I finish, please :)

[pale viper]

It's done! :D

[foggy basin]

Thanks for managing the release process, I highly appreciate it!

[pale viper]

Of course! I hope you've been having a relaxing vacation :)

[near mist]

i don't seem to be able to binstall bevy_cli on my machine

commands i've tried:

cargo binstall --git https://github.com/TheBevyFlock/bevy_cli --locked bevy_cli
cargo binstall --git https://github.com/TheBevyFlock/bevy_cli --locked bevy_cli --force
cargo binstall --git https://github.com/TheBevyFlock/bevy_cli --version 0.1.0-alpha.1 --locked bevy_cli
cargo binstall --git https://github.com/TheBevyFlock/bevy_cli --version 0.1.0-alpha.1 --locked bevy_cli --force

possible the assets attached to the github release are misnamed? should bevy-x86_64-unknown-linux-gnu-v0.1.0-alpha.1 start with bevy_cli- instead of bevy-?

[analog fern]

I think id prefer it if we just encouraged cargo install. bininstall is one more thing users need to set up, building doesn't take that long, and it makes everything more "trustable"

[near mist]

my use case is CI for context, only testing locally to make sure it works first :)

the readme in the bevy_cli repo could make installation from source the more prominent recommendation, though

[analog fern]

Yeah I'd prefer the bininstall instructions to be more of a footnote (maybe just linking to a separate file from the readme)

[near mist]

would probably be good as an expandable <details> section

[twilit dew]

FWIW I've seen quite a few CLI project move to only recommend binstall, with a footnote saying "btw you can also install from source if you really want"

There's definitely a trend there over the last few years, at least in my experience

[analog fern]

Any prominent examples you can point to?

Thats a new trend from my perspective

[twilit dew]

You know what, I think I misremembered. I went to the repos that I though were primarily advertising cargo binstall, but they nearly all have it as a second option

So never mind me 😄

[pale viper]

Could you send the error? Maybe run with --verbose as well?

Actually I'm running into issues as well on Linux and MacOS, I think it's because #455 that just merged switched the version back to v0.1.0-dev for the post-release

I remember explicitly testing it right after release and it working, which is why I think #455 is the issue

[near mist]

that makes sense. it looks at the Cargo.toml and sees the latest version is v0.1.0-dev i guess.. although it's strange it seems to ignore the --version argument

[pale viper]

Yeah, I also tried [email protected] and same result

I'm reading through the debug logs now, trying to see what went wrong

[near mist]

my guess is it checks the releases for the version you specify, can't find it because the filename isn't what it expects, so it falls back to checking the Cargo.toml in the repo where it sees the custom binstall config but also a different version number

[pale viper]

Right now we give it the following metadata:

[package.metadata.binstall]
pkg-url = "{ repo }/releases/download/cli-v{ version }/bevy-{ target }-v{ version }{ archive-suffix }"
pkg-fmt = "bin"

Even though I specify --version 0.1.0-alpha.1, it's using 0.1.0-dev for the { version } field instead. I think that's the issue

[near mist]

yeah possibly, since that's the version in the same Cargo.toml file

[pale viper]

Yup

[near mist]

which makes using that configuration a little awkward (if true)

[pale viper]

totally

After grep-ing over the logs, it only mentions the correct 0.1.0-alpha.1 version at the very beginning, everything afterwards it uses 0.1.0-dev

[near mist]

yeah that happens after Loading manifest of crate bevy_cli from workspace

[pale viper]

I'm going to submit an issue, see what the author of cargo-binstall thinks

For a temporary solution, I think we minimize / hide binstall-related docs, so users don't accidentally run into the issue

We could also hard-code the version number into the metadata for now, that would unblock your PR for bevy_new_2d

[pale viper]

Yeah, I think I'm going to go with this

[near mist]

yeah short-term i'm just happy if binstall is possible at all

[near mist]

cart wanted to do this anyways 😄

[pale viper]

I opened https://github.com/TheBevyFlock/bevy_cli/pull/458 with the fixes! If you have some free time to review it, I can merge it afterwards :)

[near mist]

approved

i've discovered that this command already works:

cargo binstall --git='https://github.com/TheBevyFlock/bevy_cli' --pkg-url='https://github.com/TheBevyFlock/bevy_cli/releases/download/cli-v0.1.0-alpha.1/bevy-x86_64-unknown-linux-gnu-v0.1.0-alpha.1' bevy_cli

it asks if you want to install the downloaded package for bevy_cli v0.1.0-dev, you say yes, and then the installed bevy --version returns bevy 0.1.0-alpha.1

[inland tundra]

Has support for mobile in the CLI be discussed before (a bit hard to search in here...)?

I am looking into cargo-mobile2 from the Tauri org at the moment and it seems like a good candidate to integrate in the CLI for commands like bevy doctor and bevy run android.

[pale viper]

I have no experience with building for mobile, but I do think it would be appreciated!

I don’t envy testing it on mobile platforms, though. That seems painful to do

[near mist]

DEBUG Checking for package at: 'https://github.com/TheBevyFlock/bevy_cli/releases/download/cli-v0.1.0-dev/bevy-x86_64-unknown-linux-gnu-v0.1.0-alpha.1'

cargo-binstall is failing to find the package because it's still putting the Cargo.toml version in one part of the url

yeah my bad i didn't catch it during review, there's still a { version } in use

[pale viper]

Oof my bad

I’ll open a PR tomorrow, unless you want to beat me to it :)

[near mist]

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

cargo-binstall is still confused about the version but now it works:

WARN The package bevy_cli v0.1.0-dev (x86_64-unknown-linux-gnu) has been downloaded from github.com

also, why does this happen on binstall?

info: syncing channel updates for 'nightly-2025-04-03-x86_64-unknown-linux-gnu'
info: latest update on 2025-04-03, rust version 1.88.0-nightly (d5b4c2e4f 2025-04-02)
info: downloading component 'cargo'
info: downloading component 'clippy'
info: downloading component 'llvm-tools'
info: downloading component 'rust-docs'
info: downloading component 'rust-std'
info: downloading component 'rustc'
info: downloading component 'rustc-dev'
info: downloading component 'rustfmt'
info: installing component 'cargo'
info: installing component 'clippy'
info: installing component 'llvm-tools'
info: installing component 'rust-docs'
info: installing component 'rust-std'
info: installing component 'rustc'
info: installing component 'rustc-dev'
info: installing component 'rustfmt'

only the first time on the same machine

[pale viper]

Weird, that’s the tool chain the linter needs

It must be because of the rust-toolchain.toml

[near mist]

yeah i was gonna say it might be picking up that file

[pale viper]

I’ll see if I can fix that when I make a PR to binstall

[pale viper]

We may need to reorganize the folders so that the linter is in a separate workspace

[near mist]

yeah that should only be needed when installing (the linter) from source

[pale viper]

That’s the only solution I can really think of

[near mist]

ok i am confusion

$ rustup toolchain list                                                         :(
stable-x86_64-unknown-linux-gnu
nightly-x86_64-unknown-linux-gnu (default)
nightly-2025-04-03-x86_64-unknown-linux-gnu (active)
nightly-2025-05-14-x86_64-unknown-linux-gnu                

$ rustup toolchain remove nightly-2025-04-03                                  :(
warn: removing the active toolchain; a toolchain override will be required for running Rust tools
info: uninstalling toolchain 'nightly-2025-04-03-x86_64-unknown-linux-gnu'
info: toolchain 'nightly-2025-04-03-x86_64-unknown-linux-gnu' uninstalled

$ rustup toolchain list
info: syncing channel updates for 'nightly-2025-04-03-x86_64-unknown-linux-gnu'
ruinfo: latest update on 2025-04-03, rust version 1.88.0-nightly (d5b4c2e4f 2025-04-02)
info: downloading component 'cargo'
stup toolchain info: downloading component 'clippy'
info: downloading component 'llvm-tools'
info: downloading component 'rust-docs'
info: downloading component 'rust-std'
info: downloading component 'rustc'
 76.0 MiB /  76.0 MiB (100 %)  65.0 MiB/s in  1s         
info: downloading component 'rustc-dev'
110.5 MiB / 110.5 MiB (100 %)  66.1 MiB/s in  1s         
info: downloading component 'rustfmt'
info: installing component 'cargo'
info: installing component 'clippy'
info: installing component 'llvm-tools'
 37.4 MiB /  37.4 MiB (100 %)  24.6 MiB/s in  1s         
info: installing component 'rust-docs'
 19.7 MiB /  19.7 MiB (100 %)  16.7 MiB/s in  1s         
info: installing component 'rust-std'
 29.9 MiB /  29.9 MiB (100 %)  24.4 MiB/s in  1s         
info: installing component 'rustc'
 76.0 MiB /  76.0 MiB (100 %)  24.8 MiB/s in  3s         
info: installing component 'rustc-dev'
110.5 MiB / 110.5 MiB (100 %)  24.8 MiB/s in  4s         
info: installing component 'rustfmt'
stable-x86_64-unknown-linux-gnu
nightly-x86_64-unknown-linux-gnu (default)
nightly-2025-05-14-x86_64-unknown-linux-gnu

why is rustup re-installing nightly-2025-04-03 when i ask it to list my current toolchains??

same thing if i replace the list command with rustup default nightly-2025-05-14 in that sequence

🙃

huh

honestly this might be a rustup bug

it's reading the rust-toolchain.toml because i'm in my bevy_cli fork

so any rustup command at all will install nightly-2025-04-03 if it's not already installed

insane

https://github.com/rust-lang/rustup/issues/4264

this is also the reason that binstalling bevy_cli in CI takes like 22s instead of 1s

oh wow, any cargo command will do the same. cargo-binstall isn't even running rustup internally

even cargo -h will start installing the missing rust toolchain unprompted

even an invalid command like cargo sdlkfjs will install the rust toolchain for 20 seconds before returning the usage error...

i guess the concept is that cargo is part of the rust toolchain, so you want to use a specific version of it for any command while in the directory with rust-toolchain.toml

maybe the command is invalid in one version but valid in another

the fix on cargo-binstall side would probably be to cd .. before running any cargo commands

actually cargo-binstall doing this seems to be based on the user's directory containing rust-toolchain.toml, not the installation target, so nvm

[near mist]

ok i tried this in release workflow, for some reason binstall is only failing on macOS

 INFO has_release_artifact{release=GhRelease { repo: GhRepo { owner: "TheBevyFlock", repo: "bevy_cli" }, tag: "cli-v0.1.0-alpha.1" } artifact_name="bevy-aarch64-apple-darwin-v0.1.0-alpha.1"}:do_send_request{request=Request { method: GET, url: Url { scheme: "https", cannot_be_a_base: false, username: "", password: None, host: Some(Domain("api.github.com")), port: None, path: "/repos/TheBevyFlock/bevy_cli/releases/tags/cli-v0.1.0-alpha.1", query: None, fragment: None }, headers: {"accept": "application/vnd.github+json", "x-github-api-version": "2022-11-28"} } url=https://api.github.com/repos/TheBevyFlock/bevy_cli/releases/tags/cli-v0.1.0-alpha.1}: Received status code 403 Forbidden, will wait for 120s and retry

[near mist]

tl;dr no need, it only happened because i ran the command while in my fork of bevy_cli, and it's not cargo-binstall's fault

[near mist]

i found this but the underlying cause looks different: https://github.com/cargo-bins/cargo-binstall/issues/1953

ok this fixed it: https://github.com/cargo-bins/cargo-binstall/issues/2045#issuecomment-2678217920

[pale viper]

Yup, any time you execute rustup or a Rustup proxy (like cargo or rustc), it may auto-install the toolchain specified by rust-toolchain.toml if you're in that directory

They released a breaking change where you have to manually run rustup toolchain install in order to get that, but it got reverted I believe

From https://rust-lang.github.io/rustup/environment-variables.html, try setting RUSTUP_AUTO_INSTALL=0 in CI and see if that shortens CI times

[near mist]

cargo binstall bevy_cli doesn't install the toolchain in CI, so should be good already

it was only on my local machine because of my pwd

[twilit dew]

TIL

[pale viper]

@rocky oxide and/or @trail shale, I wrote a small crate for the CLI that makes it easier to merge configuration together: https://crates.io/crates/mergeme. I have the PR open at https://github.com/TheBevyFlock/bevy_cli/pull/452, but currently I am the sole maintainer of the crate. Should I give the maintainers merge + publish rights, should I transfer the crate to TheBevyFlock?

The repo is currently under my personal account: https://github.com/BD103/mergeme. While I don't plan on it, if I ever become too busy to work on the CLI I'd like someone to be able to publish updates to the crate

[trail shale]

any reason to do something custom instead of using https://crates.io/crates/config?

I haven't done CLIs in a while but if I remember correctly that worked for things like default config, can be override by config file, can be override by cli options

[pale viper]

Quite honestly, I didn't know that existed!

Looking at the reverse dependencies, config is definitely popular and well maintained. I'll see how easy it would be to use that instead

Also human-panic, under the same organization, looks promising

[trail shale]

yeah it's the rust CLI workgroup, they're good 🙂

[near mist]

hm for some reason this doesn't work:

[package.metadata.bevy_cli.web]
features = ["dep:getrandom"]

output:

error: feature `dep:getrandom` is not allowed to use explicit `dep:` syntax
warning: failed to run cargo, trying to find automatic fix...
error: command `cargo build --config profile.web.inherits="dev" --features ,dep:getrandom --no-default-features --profile web-release --target wasm32-unknown-unknown --locked` exited with status code exit status: 101

[trail shale]

dep:getrandom is not a feature and you can't enable it on other crates

[pale viper]

Yeah, I believe you cannot use --feature dep:getrandom, it has to be through Cargo.toml

Hm

[near mist]

feels like --features should support the same things as [features] foo = [<in here>]

i'm sure that's a feature request and not a bug ofc

[trail shale]

well dep is a keyword to mark things that are not features, so to specifically exclude them

[near mist]

my mental model of dep was whenever you add an optional dependency it also creates an associated feature called dep:crate

apparently not

[trail shale]

well it's actually the opposite

whenever you add an optional dependency it adds an associated feature with the same name as the dependency unless you use dep: in your features to enable it

[pale viper]

Ooooo right, and using dep:getrandom means you cannot use the getrandom feature

[near mist]

okay i can kinda see how that's useful but it's so implicit

[pale viper]

@near mist for now, try switching dep:getrandom to just getrandom and see if that temporarily fixes things

[trail shale]

more precisely you're free to define the getrandom feature yourself 😄

[near mist]

in this case i do just want enabling getrandom to be the feature itself, since it's just in order to inject a feature onto getrandom 🙃

i bet you can guess which feature

[pale viper]

For the CLI, I feel like you should be able to use dep: syntax in [package.metadata.bevy_cli], but I guess using the current --features flag won't work

[near mist]

(btw quick review on this pr would be appreciated: https://github.com/TheBevyFlock/bevy_new_2d/pull/422)

[near mist]

is there support for specifying dependencies in a [package.metadata.bevy_cli] section?

[old rover]

foo = ["dep:foo"]

I slap this for each optional dependency because I hate the "an optional crate is also a feature" thing

[rocky oxide]

Yeah I really don't like that design lol

[foggy basin]

No, what would be the use case for that?

[twilit dew]

The getrandom mess :v

But we settled on just forking getrandom until something sane happens

[lusty galleon]

haven't followed super closely -- is there some particular dep that's forcing us into rand 0.9 / getrandom 0.3?

[twilit dew]

No, it’s just easy accidentally transitively depending on it, especially if you mainly test your app with native builds and only do a web build every now and then.
In our case, bevy_seedling of #1236113088793677888 accidentally brought in the new getrandom

[lusty galleon]

Ah, got it, thanks. Was just curious for my own stuff, hoping I could just keep blissfully using 0.2/0.8.

[twilit dew]

So we'd like to remove that ticking time bomb from bevy_new_2d by ensuring it’s already working with the crappy getrandom version

[twilit dew]

We got a very simple fix now: just add a patch in your Cargo.toml pointing to a fork that just works ™️

[rocky oxide]

I think we should revert that as the default option for now, given that it's not strictly necessary and there's some level of endorsement implied

But clearly document it as a workaround if needed

[near mist]

uuid can pull in getrandom v0.3 EDIT: not on wasm

bevy 0.16 depends on uuid = "1.13.1", which optionally depends on getrandom = "0.3"

the worst part is your builds can silently succeed if you don't enable the wasm_js feature or add --cfg 'getrandom_backend="wasm_js"' to your rustflags iirc EDIT: double-checked, it fails to compile

and you might think you've added the cfg to your rustflags but actually end up overwriting it in CI/CD due to setting env.RUSTFLAGS: -Dwarnings or whatever

this problem really sucks and there needs to be a solution already in the template unfortunately

[trail shale]

uuid doesn't pull getrandom in wasm

[near mist]

ah i see it's cfged

[molten merlin]

Posted a CLI video today covering the alpha/linter: https://youtu.be/B5J-X1Wx2m4

[foggy basin]

Some nice feedback on Bluesky:
https://bsky.app/profile/sakurakat.systems/post/3lqaiqkqdmc2n

Kathryn<'u1f338> (@sakurakat.systems)

I just installed the first v0.1 alpha of bevy cli, and didn't realize I'd need to install bevy lint as well. But instead of saying command not found or some other error, it detected that I need a specific version of rust installed, asked me if I want to install it, installed it.

Bluesky · May 28, 2025, 3:17 PM

[limber wedge]

Thats very nice! 😊

[twilit dew]

Oh yay they’re also happy about the template!

[pale viper]

Yeah, a nice portion of the positive feedback on the CLI are due to the fantastic defaults bevy_new_2d provides :)

[twilit dew]

Oh really? Link? 😄

[pale viper]

Looking at this comment in Chris's video specifically :)

[twilit dew]

aww lovely!

I ❤️ bevy run web soooo much 😄

[pale viper]

I know you all are in the trenches with the getrandom chicanery, but people really appreciate it!

Oh, and small PSA: I'll be slightly less active working on the CLI + linter in the following week. I've been nerd sniped by https://github.com/BD103/migrate_rustdoc_types and have some IRL events coming up :)

[twilit dew]

The CLI + linter are in such a good spot that I think that it's totally fine to leave it for a while 🙂
Really the only thing missing for bevy_new_2d's ideal workflow is bevy test web, but it's really not that important

[foggy basin]

I'm back from vacation and might have a bit of time to work on the CLI. I was meaning to ask what would be your top priorities, so I might take a look at implementing that! I also thought about taking a look at making an experimental integration of the hot patching stuff :)

[limber wedge]

Hope your vacation was good!

[twilit dew]

It’s probably a big ask, but what do you think about helping the user set up their environment so it's ready for hot patching? See the first time setup section in the readme

That part will still be necessary when hotpatching lands upstream in 0.17

At least, until Dioxus iron out all the kinks so it Just Works ™️
But according to Jon, he'll take a little break from that, as the current alpha state is good enough to experimentation

[lone hinge]

are the dioxus folks pretty firm on "this is only available to end users in our dx binary" going forward?

[twilit dew]

Nope, they’re fairly open. Thing is that they’re planning on making dx a general "Cargo CLI 2.0", so it may make sense leaving it there

[lone hinge]

unfortunate

trying to subsume cargo, I mean

[twilit dew]

Given that cargo's iteration times are best measured in geological periods, I would have done the same tbh

They want things users can use now, not in 5+ years

[lone hinge]

I get why they did it, for their users. just not a philosophy I vibe with. plus "this is procedurally difficult to work on upstreaming" doesn't transitively imply "our thing should replace upstream"

[twilit dew]

Fair enough 🙂

Anyways, they’re also open to provide a separate subsecond CLI that the Bevy CLI could call. But it's worth asking whether it should be reverse, i.e. the dx CLI calling things like Bevy Lint for us.

There wasn’t much discussion about it yet

[lone hinge]

I hope it's able to be extracted and offered separately

otherwise it feels like "I pulled in all of webpack because a workflow I tool I found attractive was written in JS" (pretend things like node/bun/deno don't exist for purposes of that analogy)

[twilit dew]

I think the situation is not as dire when talking about a binary instead of a dependency. Really, you’re just swapping one CLI for another

[limber wedge]

I personally would be way happier with a separate sub second cli that we then can call and do our stuff with. The latter feels weird. Just like we call wasm-opt or cargo etc

Gives us way more flexibility. If lets say dx would become cargo 2.0 we could just offer the user the options between cargo and dx for our subcommands but its in our hands etc

I was probably gonna start with bevy test web so a first exploration on how to integrate hot patching would be cool! @foggy basin

[twilit dew]

Mind you, if dx had some nice hooks for us to do our stuff in, we could reuse a lot of their infrastructure.

[twilit dew]

But for the moment, I definitely agree that calling them is the right move!

@upbeat yew you mean preprocessed using Bevy's builtin asset preprocessing pipelines?

[upbeat yew]

yeah, I'm not sure how bevy_cli is supposed to work with asset_preprocessing. Do I supposed to disable the asset_preprocessor feature. Do I need to set AssetMode::Unprocessed in AssetPlugin?

Is there a way I can get more logs from the webserver? even with --verbose it doesn't print any messages for those 404'd requests.

[foggy basin]

I'm always a big fan of setting up things automatically where possible!
I'll take a look at the readme. Might not be included in the first iteration, but I will definitely strive for it!

[foggy basin]

Great!

[upbeat yew]

another question. Is there an example 3d project?

I am getting a black screen and

WARN  time_system did not receive the time from the render world! Calculations depending on the time may be incorrect. log.target = "bevy_time";log.module_path = "bevy_time";log.file = "/home/user/.cargo/registry/src/index.crates.io-1949cf8c6b5b557f/bevy_time-0.16.0/src/lib.rs";log.line = 156;

oh wait. actually getting this too

Texture binding (group:0, binding:28) is TextureSampleType::Depth but used statically with a sampler (group:1, binding:2) that's SamplerBindingType::Filtering
 - While validating fragment stage ([ShaderModule (unlabeled)], entryPoint: "fragment").
 - While validating fragment state.
 - While calling [Device].CreateRenderPipeline([RenderPipelineDescriptor ""SSR pipeline""]).

250[Invalid RenderPipeline "SSR pipeline"] is invalid.
 - While encoding [RenderPassEncoder "SSR pass"].SetPipeline([Invalid RenderPipeline "SSR pipeline"]).
 - While finishing [CommandEncoder (unlabeled)].

249[Invalid CommandBuffer] is invalid.
 - While calling [Queue].Submit([[CommandBuffer], [CommandBuffer "deferred_prepass_command_encoder" from CommandEncoder "deferred_prepass_command_encoder"], [Invalid CommandBuffer], [CommandBuffer "main_opaque_pass_3d_command_encoder" from CommandEncoder "main_opaque_pass_3d_command_encoder"], [CommandBuffer], [CommandBuffer "bloom_command_encoder" from CommandEncoder "bloom_command_encoder"], [CommandBuffer], [CommandBuffer "egui_node_command_encoder" from CommandEncoder "egui_node_command_encoder"], [CommandBuffer]])

localhost/:1 WebGPU: too many warnings, no more warnings will be reported to the console for this GPUDevice.

[twilit dew]

No template, there’s only Foxtrot

[upbeat yew]

any idea if that works out of the box with bevy run web ?

and followup, if so does it work with webgpu

[twilit dew]

Yes and yes 🙂

[upbeat yew]

is there a way to pass cli args to the bevy app with bevy run web ?

[limber wedge]

Iirc it should be possible with: bevy run web — <additional bevy app args>

[upbeat yew]

bevy run web -v -- assets/scenes/cornmenu_min.glb#cctest
error: unexpected argument 'assets/scenes/cornmenu_min.glb#cctest' found

looks like no 😢

[limber wedge]

Will try to look into this after dinner. Do you have a public repository?

[upbeat yew]

I do. https://github.com/RyanSpaker/CornGame
But I actually managed to get that part working just now. I disabled the asset_processor feature and set the mode to Unprocessed.

I don't actually need asset preprocessing for anything, not sure why I had it enabled.
I'm curious what other people do, if they do use asset_processing. I'll look at foxtrot

[upbeat yew]

okay, one scene-loader editor window later and everything is working

neat

would look better with corn. but alas, no push constants. guess I need to switch to uniform buffers

[limber wedge]

Do we want to use the same styling cargo does?

[foggy basin]

For the help output formatting? Yes, I think there is an open issue for that

[foggy basin]

Nevermind, I only created issues for two other styling things. But I definitely want it!

[foggy basin]

As of late, I'm often facing the issue that compiling and checking is hogging all system resources, sometimes even making my whole PC crash...
Probably related to having multiple projects open in vscode at the same time to check the CLI.
Anyone facing this as well and found a way around it?

[limber wedge]

You could try turning off RA for other projects? For the compiling part i try to reuse the same projects as much as possible and only cleaning if necessary. But i havent had problems

[twilit dew]

Do you have a separate RA target dir? If so, I recommend turning that off and instead using a global target dir. Helped with my crashes.

[foggy basin]

I don't remember setting that up

[pale viper]

Here's something that's interesting: our network traffic for the CLI increased a lot in the past few days

Some of the top referring websites are Youtube and Itch, so I think Chris's video and the jam's page are helping a lot with visibility!

I expect we'll get quite a few issues raised and messages here in the next few days, so be prepared!

If a critical bug is found, there is a chance we'll need to release v0.1.0-alpha.2

[topaz oar]

I’ve just tried the bevy cli for the first time, and despite never having used itch before it was totally trivial to get a test game uploaded and running there in my browser. Thanks to everyone working on this - it feels like a very slick experience.

[fresh forge]

(I’m just waiting for a 3d template)

[rapid zenith]

Hi. When I follow the steps on the github page I get this error:
`Failed to resolve module specifier "env". Relative references must start with either "/", "./", or "../".``

And the browser doesn't go past the loading icon. Does anyone know how to fix it? I've tried running on Brave browser and Edge. I'm using Windows 11

[limber wedge]

Hi! do you maybe have an example or repository i can check?

[rapid zenith]

I haven't uploaded anything, nor set up itch.io, I left the fields empty when prompted by the CLI. I just installed the tool, ran it selecting the 2D template, went into my folder, ran bevy lint, and then bevy run web --open, and there were no build errors. The terminal showed the localhost url to "enter" the game.

When running the cli without the web flag, I get linking errors when compiling bevy_dylib. I'm now testing bevy by itself from scratch to see if I'll have the same issue

[limber wedge]

could you maybe share your Cargo.toml?

[foggy basin]

Are you using nightly? I encountered the same bug with a specific nightly version, but it's fixed now. You can try running rustup update to fix it

See https://github.com/rust-lang/rust/issues/141085

[rapid zenith]

I am using nightly and the update did work, so thank you!

and thank you @limber wedge as well!

[sturdy tapir]

bevy_lint is a rustc driver right?

how hard would be for yall to add a step to register all component/event/resource types on compile?

[limber wedge]

yes

[limber wedge]

its possible in theory i think (very hard) but not something we should do. i think modifying the code via rustc_driver is not a good idea

we just also need a bevy lsp

[lone hinge]

there's stuff like the inventory/linkme crates that allow it to happen in a custom mildly hacky way for rust code in general, and https://github.com/TGRCdev/bevy-butler if you like proc macros

haven't tried the latter, not to my taste

[twilit dew]

Some people need help FYI 🙂

[shrewd monolith]

Okay so I resolved my issue here. Turns out an an external path had changed, so the Cargo.toml became invalid. I guess the only actionable thing for the cli here is maybe a bit more info in the error -- not sure how easy it is, but with that info I could have resolved my issue right away!

[shrewd monolith]

The error is, for context:

error: failed to obtain package metadata, are you in a cargo workspace?
The reason for this error could, of course, be extremely varied.

[limber wedge]

Yes we should forward the cargo metadata error (at least in verbose mode)

[foggy basin]

Fair, honestly also in normal mode. We can omit the normal output, but if the command failed we should forward the whole output to aid debugging

[lofty sorrel]

Hello. I'd like to contribute to resolve the "Log requests when using bevy run web --verbose #423" issue and would appreciate some input as to the preferred method of enabling or disabling the output.

Adding the desired logging output should be trivial with an included tower-http middleware, so it just has to be decided if the toggle should be editing the tracing env filter, or should be inside the middleware. Or both I suppose. The former option seems preferable to me, but I dont know that I have a particularly convincing reason for that. Apologies if this is not the correct place to ask this.

[limber wedge]

Thanks that would be highly appreciated!

[limber wedge]

My initial thoughts was to probably set the default level for request and response to debug.

So currently if the —verbose flag is set we set the trace level to debug.

[pale viper]

I agree! A normal web server usually logs requests as info, but in this case developers don't really care about the requests unless something isn't loading

Speaking of logging, I wonder how easy it would be to pipe the WASM app's stdout to the bevy run web stdout. This would let people avoid opening up their browser's developer console, and we could filter out the messages that should be ignored

[trail shale]

You would need to open a connection between the bevy cli and the app, and set a subscriber in the app that sends logs through that connection

The hard generic version is to wrap a server in the wasm app that anyone can connect to to get logs/diagnostics of a running app

The easier version is to put the server in the CLI and then the app connect to it on start, and sends logs. Ideally set up the server so that it can send message when the client connect, and you have a way to use BRP in the cli in wasm

[foggy basin]

We already have a websocket between the CLI and the browser, so we should just need to pipe the things from the bevy app to the JS, maybe through message passing to the window

[trail shale]

In that case you should already be able to catch logs in JS

[lusty galleon]

i believe https://github.com/jakobhellermann/wasm-server-runner had this sort of setup

[pale viper]

Looks like it overwrites console.log() and assorted methods with a custom version that passes the messages over websocket. Cool!

[fresh forge]

ehm

anyone know why it suddenly did this?

[fresh forge]

reinstalled and it seems to be working again but that was very weird

[foggy basin]

No idea. Sounds related to your anti virus software

[fresh forge]

Yeah it kept popping up, but when I clicked it I got an empty screen

Super odd

[foggy basin]

Are you using Windows defender or another virus software?

[fresh forge]

Windows def

[foggy basin]

Thats annoying. Not sure if we can change something on the CLI side to not get flagged like this?

[fresh forge]

Idek why it was flagged since defender didn’t load when I asked for more details

[limber wedge]

maybe we could also take a look at: https://github.com/SergioBenitez/Figment @pale viper (not sure how maintained it is)

[pale viper]

Looks interesting, I’ll definitely check it out!

[molten merlin]

I've seen a few people have trouble with the readme having template values in the install instead of the actual version. I assume that's done that way to try to ease maintenance but it would probably be better for end-users if the commands were actually copy/paste runnable.

[pale viper]

Makes sense, opening a PR for this now!

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

[limber wedge]

how does this work for the cli? its not like others have the cli / linter in their lockfiles

[rocky oxide]

Maybe it's getting pulled in in their CI and Github can detect that?

[limber wedge]

ohh! yess that nees to be it since its in the 2d template ci

[near mist]

and now we know how many people use the 2d template 😈

bevy_analytics

[foggy basin]

It's actually seemingly tracking the linter, I bet it's the GitHub action that's being tracked

[near mist]

this must be all the wip jam games, since bevy_lint was not added to the template until recently obviously

[limber wedge]

yep!

[near mist]

although it's interesting, i'd expect a lower number considering not everyone uses the template for the jam (and most jams get 70-80 submissions), so there must be some other things mixed in

[rocky oxide]

Jam games started >> jam games finished 🙂

[brittle anvil]

❯ bevy new -t 2d station
error: error sending request for url (https://api.github.com/orgs/TheBevyFlock/repos)

I do not know what is wrong

[lone hinge]

wild-ass guess - anonymous rate-limiting done by GitHub that got substantially more aggressive about a month ago

[brittle anvil]

is it possible to not be anonymous?

[lone hinge]

i'm not a CLI contributor but I would guess no, just don't take my word for it

they'd have to use your pre-existing personal auth tokens which would be kind of a no-no to do without being asked to, and aren't even stored in a particularly standardized way/place if you don't shell out to their gh cli

I do think you can give a full repo URL in the -t argument and it might bypass the lookup

[brittle anvil]

does not appear to be the case

It's so consistantly that I don't know that it's rate limiting. The tool hasn't worked once

[lone hinge]

AFAIK the rate limiting is enforced by client IP (i.e. everyone behind your home router) and would include counting browser traffic poking around in repos in any tab you weren't signed in on or from mobile devices or the like. I hit it now and again with searching stuff from my phone.

[brittle anvil]

I have a public ip so that's much less likely for me i'd imagine

[lone hinge]

their docstring claims a full URL would work https://github.com/TheBevyFlock/bevy_cli/blob/edb69bdbc57fe55936728ebda9af26e56a854b9c/src/bin/main.rs#L202-L203 and it just inlines cargo-generate called as a library https://github.com/TheBevyFlock/bevy_cli/blob/edb69bdbc57fe55936728ebda9af26e56a854b9c/src/template.rs#L25, so you could try cargo generate --git https://github.com/TheBevyFlock/bevy_new_2d.git if you have it installed?

I'm gonna be stepping away for the rest of the evening momentarily, so if that also doesn't help, i'm sorry

[brittle anvil]

Tried cargo generate, and cargo's giving me an SSL error. That's probably why the other one was failing.

[lone hinge]

ralph-wiggum-im-in-danger.gif

probably correct tho

[brittle anvil]

Would be nice if the error message wasn't so vague, but I don't know if that's because of bevy cli or whatever it's using

[lone hinge]

if you can clone it successfully through whatever other means, there's a cargo-generate command flag to use a local template folder instead but I don't know it offhand

gotta scoot, good luck!

[brittle anvil]

I'll probably just try to figure out whatever the SSL issue is as I think it's been plaguing my pc quite a while... thanks for the help though!

[pale viper]

Hi! I'm sorry you've been running into this, I believe @lone hinge was right to suggest specifying the full URL. I've added a comment to #309, which tracks support for passing the Github token

[foggy basin]

I count this as a win for the CLI and 2D template :)

[foggy basin]

Percentage last year was 88%, so 94% is a decent increase

[shrewd monolith]

The CLI actually did save me 😅 our (non-CLI) wasm workflow wasn’t producing a functional bundle, and I wouldn’t have had time to figure it out if I couldn’t just pivot to the CLI and bevy build it.

[foggy basin]

Great to hear that!
I'm curious, which wasm setup did you use before?

[shrewd monolith]

It was using trunk before (although I didn’t look into the details, someone else set it up). For some reason the JS was getting a 403 when trying to fetch the Wasm from itch. Can’t say what the underlying problem was

[foggy basin]

The 403 is returned by itch when a file is not available, eg the asset meta files. In theory the same should happen with the Bevy CLI :D
But I'm happy that it got fixed somehow!

[lusty galleon]

For some reason the JS was getting a 403 when trying to fetch the Wasm from itch.
Different problem. @shrewd monolith
Second bullet point here: https://github.com/bevy-cheatbook/bevy-cheatbook/issues/253

[foggy basin]

Finally had time to fix the workspace resolution bug: https://github.com/TheBevyFlock/bevy_cli/pull/477

[pale viper]

If there are any Nix / NixOS users listening, could you spot-check the updated install instructions I wrote for the linter in #478? You can view the instructions at https://github.com/TheBevyFlock/bevy_cli/blob/linter-sysroot-var/docs/src/linter/install.md

I don't have Nix setup on anything, so I'm not easily able to test the Nix-specific things I wrote :)

[dusky onyx]

I'll test it on my work project with NixOS, that's a good excuse to finally try out the linter

[pale viper]

Thank you! The installation instructions are currently generic for non-Rustup users. If you get a good Nix setup that works, I can add a section just for Nix users :)

Ping me in this channel or leave a comment on the PR if you get stuck!

[lone hinge]

I just packaged both binaries in my devShell via nix itself, appears to work fine over the last week or so

I use the same nix flake on macOS and NixOS, and I never cargo-(b)install anything

[dusky onyx]

That's cool, we should probably add them to nixpkgs as well when they become a bit more stable

[lone hinge]

I personally don't contribute to nixpkgs anymore until they sort out their governance problems, and I use the tool itself fairly begrudgingly

more power to anyone else who doesn't have the same hangups

[pale viper]

I'm curious about this, could you go into a bit more detail? Right now we're planning on adding the CLI to nixpkgs (https://github.com/TheBevyFlock/bevy_cli/issues/441), as I thought it would receive better testing and greater accessibility

Originally a user suggested adding a Nix flake, but I eventually decided against it in favor of eventual nixpkgs. If there might be issues with that, however, I would reconsider

What kind of governance problems are there that we may run into while trying to add support for the CLI?

[lone hinge]

if you'd like to we could DM about this tomorrow to dig in more to the messy color + context. I'm in UTC-6. tldr my backing away is at least as much ideological/political reservations as technical dissatisfaction but there's plenty of both. I can't answer for anyone else whether the same things will matter to them to the same extent, but there's a lot of contrast to say, the rust community's professed values, or this one's.

but practical answer is that as a publisher-of-software you're probably not going to feel the effects very much. most of what I'm about to write is going to be "that just sounds like volunteer FOSS dev".

nixpkgs has poor reviewer throughput IME and some tech debt, and the SDLC they use means that that there are some competing tensions/perverse incentives. reviewers can be capricious about adherence to unenforceable subjective idioms, git hygiene, etc. and the language is a little too arbitrarily flexible. the hydra CI platform is thorough in some ways but sucks a lot compared to what a lot of projects are accustomed to and there's non-trivial rules about parallel git branches and backports, junk like that. In particular if you care about Mac and/or ARM clients there's some tough outcomes because CI hardware is expensive and the foundation is mismanaging pretty much everything fiscal IMO.

a lot of publishers just spend the one-time effort cost to share an update script within nixpkgs repo alongside their package definition, and then a bot will perform future updates for you on a slow cadence ala dependabot. Rust crates with github releases or git tags is a pretty low lift with fairly easy prior art.

I can't imagine nixpkgs as a target having better reach or more attractive audience than prioritizing something like homebrew + binstall + maybe a mise-en-place plugin or something, which is also a pretty low lift.

I wouldn't PR any of my own authored software to nixpkgs even if I believed it would have a good chance of getting accepted, because first-party flakes are a lot better experience for most nix users/use-cases

I'd definitely totally ignore projects like flox or devenv

nixpkgs' merge cadence makes way more sense for something that is relatively stable/done and not going through lots of sub-1-week iterations, and the stable-channel vs unstable split makes it even more high friction for very early projects. They basically pin whatever major version of your package was available when ie nixos 25.05 release was cut and don't do interim bumps until the next ~twice-yearly release. at least that's the soft rule on paper but they're fairly unprincipled/inconsistent with how they apply that expectation.

[pale viper]

I see. Those are some good reasons to support flakes instead, but @limber wedge @foggy basin I’m curious what you both think about it

I feel like I’m too on the fence right now to decide

[limber wedge]

Im a total nix noob so maybe im wrong.

But for me i dont see a big benefit in supporting flakes until we have an active maintainer who needs / uses them. The linter and cli should be useable for nix folks (this is very important) but its in their responsibility to make it work with their setup. We also dont have special support for other operating systems.

And i Imagine if we get upstreamed and release on crates the nix folks can easily add it in their package manager?

[lone hinge]

"if you break it, you get to keep both pieces" should be a familiar experience as a nix user and not something they react to with a lot of negativity or blame. it's a long term exercise in patience and fragility because nothing else is quite like it and it inflicts a lot of its own problems - like any "clever and I mean that pejoratively" technical solution.

building a nix package for a crates.io release can often be about 10-12 lines of nix syntax total but that actually doesn't get substantially easier or harder compared with git tags.

for the issue link up above I would challenge whether inclusion in nixpkgs would actually convey any meaningful sense of "better tested". it's a bit like assuming a piece of software is more stable because it's on the Debian apt repos. it might be, but it's definitely not a causal relationship and not in the direction of Debian->more stable. and nixpkgs are fairly mercenary that if a package doesn't have an ongoing stakeholder that maintains it in nixpkgs and responds to PRs, it can be summarily dropped again.

[pale viper]

Ok, then I think the best path for now is to have #478 be the extent of Nix support. We'll make it possible to use the CLI and linter on Nix, but won't have explicit instructions or guaranteed support for using it

That means closing #441 as not planned

It's probably a good thing anyways, as we couldn't really go forward with #441 until the CLI and linter become upstreamed / official

[buoyant jasper]

Hi folks from the flock! I'm facing an issue after updating to rust 1.87. Looks like LLVM was updated in this version and when I try to use the CLI like this:

bevy build --yes $BUILD_PROFILE web --bundle

I'm getting errors like Bulk memory operations require bulk memory [--enable-bulk-memory] (this is expected by the new LLVM version it seems) but I think it's not possible to pass down flags to wasm-opt yet, right?

FWIW I'm running this with GitHub Actions. I can provide more details of the errors if required but maybe someone already faced this issue and knows how to sort it out. I guess I can always roll back to the previous rust version for the time being.

[foggy basin]

It's not possible to pass flags to wasm-opt yet, that's on my list of things to improve.
In theory you could disable the wasm opt feature in the CLI and run wasm-opt manually with the flags you want, but then you won't be able to install the CLI via cargo binstall anymore, so it's probably not worth it

[foggy basin]

@limber wedge can you take another look at https://github.com/TheBevyFlock/bevy_cli/pull/477 when you find the time?
I improved the documentation now, but would be good to get it checked again in case I missed something.
If it works for you, feel free to merge!

[limber wedge]

Yes will take a look in the afternoon!

[buoyant jasper]

I ended up rolling back to rust 1.86 to fix this issue.

[foggy basin]

Does the error occur when running wasm-opt?

[foggy basin]

@buoyant jasper FYI, you can follow https://github.com/TheBevyFlock/bevy_cli/issues/442 to get updated when we work on custom wasm-opt flags :)

[foggy basin]

I fixed a bug which prevented the actual use of custom web targets, e.g. wasm32v1-none:
https://github.com/TheBevyFlock/bevy_cli/pull/481
@limber wedge FYI I restructured bevy_complex_repo a bit to make it easier to use.
I now recommend to open the VS Code workspace bevy_complex_repo.code-workspace instead of the folder, that makes it easier to run the CLI in the different Cargo workspaces :)

[limber wedge]

(now i just need to know how to use vs code workspaces)

but while the bevy_complex_repo is very handy its also a big pain point and we should get to a point where its not out "only" "does it work" test ^^ (dont get me wrong its lovely for now)

Im just not sure yet how we can get there easily without sacrificing CI time etc maybe we can look to cargo for inspiration.

[foggy basin]

Yes, that will require some thought. Maybe for some of these workspace setups we can add a pipeline that's only manually triggered, or on a weekly schedule, so we don't kill our iteration speed but also get the confidence that we didn't break anything when we need it

I was also thinking about experimenting with automated Playwright tests in bevy_complex_repo.
Then we could take a screenshot of the test "game" to really validate that it loaded, but it probably wouldn't work in CI due to the missing GPU. But that could simplify manual testing

Probably makes sense to experiment with multiple approaches.
I consider stability of the CLI a very high priority, if users start to doubt that it works as they expect it will push them away

[limber wedge]

Yea a combination of both would be nice. Iirc cargo just checks the stdout of their command something like this would already be nice but we definitely need to also have tests that check the actual running app

[limber wedge]

Yes

[foggy basin]

On the other hand, there is also more cases we could cover with unit tests. The binary selection is one good example for this

[twilit dew]

Fellas, I have a problem

I use the bevy CLI alpha so much, that I forget cargo exists

I just typed bevy add avian3d and was confused why it didn't work

[limber wedge]

Yea that one definitely should have some

[foggy basin]

Honestly, that's the best feedback we could hope for! 💚

[foggy basin]

You'll be happy to know that @limber wedge opened a PR for bevy test, if you could test that it would be highly appreciated!

(I wanted to try it out today, but then found a bug that I had to fix first)

[limber wedge]

But yea i have only labeled it as „needs testing“ iirc because i dont really have good tests and i didnt have the energy to think over the past few super hot days to create them

[twilit dew]

just run it on avian's test suite 😉

[limber wedge]

Well the native tests are easy

[twilit dew]

that one is fairly in-depth

They should all also run for web

(I believe)

[limber wedge]

That would be very handy

[buoyant jasper]

You mean if I run it individually? I haven't tried honestly, I could try some other time and confirm.

[foggy basin]

I mean at which step of the build process the error occurs :)

[buoyant jasper]

Oh, yeah I can check that later in the build logs and report.

[foggy basin]

Awesome, thanks!

[pale viper]

I believe macos-latest runners do have GPUs because they run M1 chips, so you should be able to use them with Playright! :)

[limber wedge]

what about a bevy docs command that opens the docs.rs for the version specified in the cargo.toml? Or maybe i just need to finally bookmark it

[twilit dew]

Tip: in duckduckgo, typing !drs bevy brings you there 🙂

!drs foo in general brings you to the docs.rs page for foo

[limber wedge]

🤯

[lone hinge]

plug for cargo doc --open -p if you're in the project at the time

I most often use docs.rs if I'm not at a real computer and gen local docs otherwise, since it will match my actual crate versions and enabled crate features

[limber wedge]

that is sooo handy nice thanks for the hint!

[pale viper]

@twilit dew would you mind going into a bit more detail on why camera-related code should be in Update and not FixedUpdate? Specifically, why is it bad? What happens when you put it in the wrong schedule? Are there any exceptions? I'm reviewing https://github.com/TheBevyFlock/bevy_cli/pull/417 and want to go into a bit more detail in the lint description.

[twilit dew]

Sure! It's because it's very noticeable when the camera does not updates every frame. You want to have a low motion-to-photon latency, e.g. the latency between you moving the mouse and the game moving the camera.
If you have delays in there, it quickly feels sluggish.
This is all well and dandy when you first start using Bevy and only use Update anyways. But then you start learning about fixed updates at some point and learn that physics engines use them.
Now you want to build e.g. a first person game where you press W to move in the direction the mouse is pointing. The scheduling here becomes tricky to get right. Essentially, you want to make sure that in a single frame, all of the following happen:

• The input is read (maybe some mouse movement and the player pressing W this frame)
• The camera is rotated
• If there is no fixed update, accumulate the movement input somewhere so it's not lost
• If there is a fixed update, apply the accumulated movement input
• Interpolate the rendered transform smoothly between fixed update values
• Synchronize the camera position with the interpolated physical character position

Not sure how much you know about schedules, so please tell me if any of this sounds confusing so far 🙂

If you get the ordering of these things wrong, the following can happen:

• Ambiguities: your game is no longer deterministic and things like networking woudln't work correctly
• Swallowed inputs: fast machines will have some frames that just ignore inputs
• 1 frame delays: Don't really matter on fast machines, but really matter on slow ones
• Laggy camera: The camera is not reacting to your input every frame, which feels very laggy

There are some variations and pros/cons for where to schedule these things to avoid these issues, but AFAIK, this is the current "standard", though it's not really explicitly written down in any example yet, but instead strewn around the docs:

• PreUpdate (variable timestep): read input and set character controllers / accumulate input
• RunFixedMainLoop, RunFixedMainLoopSystem::BeforeFixedMainLoop (variable timestep): rotate camera
• FixedMainLoop, RunFixedMainLoop::FixedMainLoop (fixed timestep): update physics, e.g. move character in the direction the camera is facing by draining accumulated input
• RunFixedMainLoop, RunFixedMainLoopSystem::AfterFixedMainLoop (variable timestep): interpolate transforms
• Update: Move camera translation to interpolated physics translation

So this is my review of schedules I've seen camera code in. Note that this is for mutating camera code:

• PreUpdate: bit of a footgun because it happens before state transitions, so I would discourage it, but it's not strictly wrong
• RunFixedMainLoop, RunFixedMainLoopSystem::BeforeFixedMainLoop: last variable timestep before fixed loop. Good place.
• FixedMainLoop, RunFixedMainLoop::FixedMainLoop: will make the interactions lag, don't put it here.
• RunFixedMainLoop, RunFixedMainLoopSystem::AfterFixedMainLoop: first variable timestep after fixed loop. Can be a footgun if you're not aware that interpolation happens here
• Update: well, good old update. Good place.
• PostUpdate: footgun again because of transform propagation and camera visibility updates happening here. Would discourage

Does this make sense @pale viper ?

[foggy basin]

Sorry to interwene, I just opened a PR for another workspace improvement.
You can now define custom web assets for a single package, instead of always for the entire workspace:
https://github.com/TheBevyFlock/bevy_cli/pull/485

[pale viper]

I think so, but I have a few follow-up questions if you don't mind! Mainly:

• Variable timestep means the time between running systems could change, right? And fixed timestep means there's a constant amount of time between running a system?
• Why do you recommend rotating the camera and translating the camera in two different schedules?
• The docs for BeforeFixedMainLoop recommends putting camera code in there instead of Update. Do you have a preference / when would it matter?

[twilit dew]

Check out https://bevy.org/examples/movement/physics-in-fixed-timestep/ for a more in-depth description I wrote a while ago 🙂

But the gist is:

• variable timesteps happen every frame, and may take an unknown amount of time, dependending on workload
• fixed timesteps wait until a certain amount of time has passed over n frames, e.g. 16.6 ms Then they run as many times as they need to "catch up". That means a fixed timestep will run 0, 1, or n times each frame

[pale viper]

Ooooo that looks like a good read!

[twilit dew]

For example, let's say that a fixed timestep is targetting 10 ms. Let say we just started the app and the first frame took n ms. We are now on the second frame and need to decide whether to run a fixed update.

• If n is 1 ms, we don't run a fixed update, since we target 10 ms
• same if n is 5 ms
• if n is 10 ms, we run one fixed update. We are now behind by 10 - 10 = 0 ms
• if n is 13 ms, we run one fixed update. We are now behind by 13 - 10 = 3 ms
• if n is 20 ms, we run two fixed updates. We are now behind by 20 - 2*10 = 0 ms
• if n is 27 ms, we run two fixed updates. We are now behind by 27 - 2*10 = 7 ms

We carry that time we were around over to the next frame

For example, if we are behind by 3 ms after the fixed update, and our entire frame took 5 ms, we would be behind by 3 + 5 = 8 ms

which is our new n for the next frame

[twilit dew]

Second point: It's an ordering thing.

• In order to walk, the character needs to know the rotation of the camera.
• In order to move with the character, the camera needs to know where the character ends up in this frame
  So, the order must be
• rotate camera
• run physics
• move camera
  this ordering corresponds to the systems I posted above 🙂

[pale viper]

Ah, that makes a lot of sense

[twilit dew]

Third point: I remember writing those docs 😄
Yes, you put them there in the rare case when the physics depends on the camera. That is pretty much only the case for camera rotation. Most camera mutations go in Update.

[twilit dew]

At the risk of repeating myself, to be explicit: pressing W in a 3D game that is not top-down usually moves you in the direction the camera is facing

[pale viper]

Thank you very much! I think it all makes sense now, but I’ll let you know if I have any more questions!

[foggy basin]

PR to allow users to change which flags are passed to wasm-opt:
https://github.com/TheBevyFlock/bevy_cli/pull/486
CC @buoyant jasper and @near mist as you both requested this feature :)

[foggy basin]

As a follow-up we should probably look at our default flags again, if we can improve them.
See https://github.com/TheBevyFlock/bevy_new_2d/issues/402 for a lot of metrics on this

[limber wedge]

Always a good excuse to take a study break 😂

[gleaming plank]

Minor inconvenience I just tripped on: bevy build web --bundle doesn't behave as expected in a workspace

For clarity, I have my client and server as subfolders. When I was working in the Jam, I just had the client, and it was at the root; after I migrated to this broader structure, I tried to run the web release script again, but it couldn't find my assets folder

When I run with cargo run, the assets folder is found in client/assets, but bevy build web --bundle only checks assets

I can get around this I think by doing cd client && bevy build web --bundle, but that doesn't seem ideal

[limber wedge]

yea we have to fix this! thanks for reporting https://github.com/TheBevyFlock/bevy_cli/issues/489

[gleaming plank]

Happy to!

I love the CLI in general; I haven't messed with it much, but I have a feeling it's going to become vital to my workflow within the next few months lol

[lusty galleon]

Has anyone encountered this error when bundling a release build with v0.1.0-alpha.1?

[parse exception: invalid code after misc prefix: 17 (at 0:33299274)]
Fatal: error parsing wasm (try --debug for more info)
error: command `wasm-opt --strip-debug -Os -o /home/runner/work/my_package/my_package/target/wasm32-unknown-unknown/web-dist/my_package_bg.wasm /home/runner/work/my_package/my_package/target/wasm32-unknown-unknown/web-dist/my_package_bg.wasm` exited with status code exit status: 1

Some googling lead me to https://github.com/leptos-rs/cargo-leptos/issues/526

Building in CI with:

cargo install --git https://github.com/TheBevyFlock/bevy_cli --tag cli-v0.1.0-alpha.1 --locked bevy_cli
bevy build --yes --release --profile web-dist web --bundle

edit: seeing this locally too after a fresh cargo install wasm-opt.

[pale viper]

Does this look like #1278871953721262090 message ?

If so, I think you can fix it by passing flags to wasm-opt

https://github.com/TheBevyFlock/bevy_cli/issues/442 hasn’t been released yet, but you should be able use it from main!

[lusty galleon]

I am not sure. It seems like it should be related, but adding the flag mentioned in this thread, or other flags mentioned in related GH issues doesn't seem to help.

[parse exception: invalid code after misc prefix: 17 (at 0:33299529)]
Fatal: error parsing wasm (try --debug for more info)
warning: failed to run wasm-opt, trying to find automatic fix...
error: command `wasm-opt --output /Users/me/src/my_package/target/wasm32-unknown-unknown/web-dist/my_package_bg.wasm /Users/me/src/my_package/target/wasm32-unknown-unknown/web-dist/my_package_bg.wasm --enable-bulk-memory --enable-nontrapping-float-to-int -Os` exited with status code exit status: 1

[foggy basin]

Sounds like the upstreaming process might start soon-ish?

[lusty galleon]

Okay, so I think I missed some details in the github issues. It seems that the wasm-opt crate is out of date, version 116. Downloaded the binaries for 123 and that version of wasm-opt seems to work with or without the extra flags.

(downgrading to rust 1.86 also made things work w/ wasm-opt 118)

seems like the apt package has binaryen 120, going to see if that's new enough. edit: no dice.
trying with https://github.com/sigoden/install-binary. edit: success

[limber wedge]

hm i didn't follow the wasm-opt issue too closely but from the issue it seems like the problems were in the wasm-opt crate and we switched to using the binary only a few months ago so this is rather interesting. Did you maybe have an old version installed?

[lusty galleon]

I didn't have any version installed, I let bevy_cli install it for me. Afaik, it installs it with cargo (and that version is outdated)

I have resolved this now by installing binaries from the latest binaryen GH release instead.

[limber wedge]

ohh i see thats annoying

Maybe we have to switch to installing from the GitHub releases as well. The current method is a bit too ""unmaintained"" imo

[twilit dew]

Thanks @limber wedge for eliminating this footgun! https://github.com/TheBevyFlock/bevy_cli/pull/417

and good luck with your exams 🙂

[limber wedge]

Thankkk youu! Still a nursery lint as it has some limitations but its a first step

[foggy basin]

Good luck, you got this!

[pale viper]

Somewhat related: in the next few days I'm going to try to catch up with the open PRs and do some much-needed chores. I haven't been too active recently due to mild burnout and IRL business, but I think that's mostly over :)

I'd also like to establish a vision for "what does the next release look like?" for both the CLI and linter. I personally feel like I need a bit more direction figuring out what to work on

Also, now that the game jam is over, I'd like to reopen the conversation on how we might begin upstreaming the CLI and linter. I think that's a great north star for us as a working group, even if it will take a few more releases to get to that point :D

[rocky oxide]

@trail shale may have plans 😈

(I discussed these with @analog fern briefly and he was on board too)

[pale viper]

Ooooo, exciting! I saw from the notes you wrote that he wanted to upstream the CLI "one function at a time, being strict", and I'm curious to hear what that may be

[rocky oxide]

The basic strategy here, from what I understand, is to create a bevy_cli crate approximately now-ish

Then we pick the most mature, least controversial functionality

And we refine / review / improve it until it's ready to merge

Either in the bevy_cli repo, or via PR review

And then we repeat

[pale viper]

Ohhh so somewhat "reimplementing" the CLI with the hindsight of our current implementation

I can get on board with that. There are some things the CLI does that I think could be abstracted better

[rocky oxide]

Yep, copy-pasting where feasible

Yeah, or where we could leverage existing tools better or whatever

I a) haven't done a proper review and b) am not a CLI expert, so I don't personally have strong feelings here

But process-wise, i think this is a pretty reasonable approach

And one-function-at-a-time allows us to deliver cohesive, valuable work

[pale viper]

How do you think the linter may be upstreamed? Should / could it?

Mainly it has a larger maintenance burden than the CLI, and is incredibly domain-specific

[rocky oxide]

I think it's one of the most valuable bits

I'm reluctant to do so while the UX for using it is still kind of ass though

[pale viper]

Lol very fair

[rocky oxide]

So until we a) see upstream Rust improvements for this (desired, slowly being worked on) or b) ship a Bevy language server that we can embed it in, it will probably live in "upstream eventually" territory

[pale viper]

Hmm. The CLI can install the linter if you don't have it already, so maybe we could give it more powers in that realm

There are some real sharp edges with the #![register_tool(bevy)] nonsense, however

[rocky oxide]

Yeah

[pale viper]

I haven't considered making a language server for the linter, but I could see that working. I would much rather integrate with Rust-Analyzer, though

[rocky oxide]

The other thing I'll note is that we'll want to dogfood lints (and the linter) in CI on Bevy itself before shipping

[rocky oxide]

I think we're likely to want a Bevy Analyzer already, primarily for .bsn files and the bsn! macro

I know @analog fern did some experimentation there

[pale viper]

Would you be open to adding the linter to CI in its current state, before it's upstreamed? We already have a Github Action for it

Last time I brought up adding it to CI, I know the thought was to disable all lints but a select few. Are we at the point that we could try it?

[rocky oxide]

I am pretty "let's fuck around and try it" in CI

But that is firmly a @trail shale decision IMO

[pale viper]

Agreed

[rocky oxide]

And yeah, turn the lints on one at a time

[pale viper]

Lovely! I'll add a task in my planner for that, and wait to hear from Francois and the other CLI / linter maintainers about the other stuff :)

[rocky oxide]

My first choice of lint would be the "did you remember to reflect and register everything" stuff

That one is very uncontroversial and delivers immediate value

[pale viper]

Gotcha, that's definitely a good one to prioritize

The reflection lint has a few quirks right now, and the other registration bits shouldn't be too difficult to add

I would also like to reorganize + replenish the linter contributing guide. There's some topics I'd like to write about, and I'm unhappy with how things are laid out currently

But that's not as relevant to upstreaming, I suppose :)

[rocky oxide]

Eh, it'll be nice Contributing Guide material

[twilit dew]

I assume the current CLI with the controversial bits will still be available during that process?

Asking because I'm a Bevy CLI power user at this point and wouldn’t want to lose it lol

[pale viper]

I believe so! Though there may not be any new features if we focus all of our efforts towards upstreaming

[twilit dew]

Yeah it’s so good rn that I'd be completely fine with a feature freeze 🙂