#bevy_cli

1 messages · Page 3 of 1

limber wedge
#

Yea sorry about that xD

limber wedge
#

adding similar functionality than cargo bless would be nice too

versed sparrow
#

what is #![deny(bevy::zst_query)] doing in the lint tests ? tests/ui/zst_query/query.rs

#

I'm trying to test the linter I wrote, but it's not producing anything. I registered the linter and added it to the slice lints in LINTS. I've debugged it and verified that it does indeed call span_lint_and_help, but still nothing. FAILED TEST ... test got exit code status: 0, but expected 1

#

The only thing I can see that might be different is that I haven't added #![deny(bevy::sus_resource)] (just a temporary name for now), because it says :

3 | #![deny(bevy::sus_resource)]
  |         ^^^^^^^^^^^^^^^^^^ Warn: unknown lint: `bevy::sus_resource`
limber wedge
#

Eh the deny is so it produces errors and not warnings

versed sparrow
#

I see, so i think I need to enable that

#

I can't tho because I get unknown lint

limber wedge
#

So it checks the .stderr file

versed sparrow
#

Yes

versed sparrow
limber wedge
#

Yea seems like something is not working with registering the lint correctly. Im on phone but maybe i could take a quick if you have a link

#

Do you have both the declare lint / declare lint pass and registered them both?

versed sparrow
#

cargo dev new_lint --name=foo_functions --pass=early --category=pedantic (category will default to nursery if not provided)

Does this command work for bevy_lint ?

limber wedge
#

No i dont think it does maybe BD103 can confirm but we haven’t implemented/ migrated any of the dev tools that clippy has

limber wedge
versed sparrow
#

src/lints/sus_resource.rs :

declare_bevy_lint! {
    pub EVENTS_RESOURCE_SYSTEM_PARAM,
    RESTRICTION,
    // FIXME: Better note.
    "use of bad system parameter",
}

declare_bevy_lint_pass! {
    pub EventsResourceSystemParam => [EVENTS_RESOURCE_SYSTEM_PARAM.lint],
}

src/lints/mod.rs :

pub(crate) static LINTS: &[&BevyLint] = &[
  sus_resource::EVENTS_RESOURCE_SYSTEM_PARAM,
  ...
]

...

store.register_late_pass(|_| Box::new(sus_resource::EventsResourceSystemParam::default()));
#

Ok I fixed it

#

it uses the name provided in the macro as the linter name thing

#

So what do I do when I think the lint is finished ? I'm considering just leaving my bad names and error messages and just letting whoever reviews the PR to tell me what would be the most apporiate messages / lint level

limber wedge
#

If your lint fixes an open issue you could reference that in the PR otherwise just create a PR with a short description what the lint does / should prevent. I would still try to name it properly, the reviewers can still rename it but chance is that it fits. And it helps the reviewers aswell understand the purpose better.

versed sparrow
#

I feel like I may have no understood the issue, but not sure how else I could have interpreted it

limber wedge
versed sparrow
earnest gate
#

my environment has rustup and cargo, but i've never been able to cargo +[toolchain], so whatever hardcoded cargo +toolchain command is in bevy_lint doesn't work; i'm going to try figuring out if there's a specific way of configuring cargo that allows this, but surely there should be some easier workaround

image.png
earnest gate
#

i'm pretty sure i got it working with env RUSTC_WORKSPACE_WRAPPER=/home/gigamicro/.cache/cargo/bin/bevy_lint_driver rustup run nightly-2025-01-09-x86_64-unknown-linux-gnu cargo check, but i can't actually verify since it didn't detect anything...

#

are there any test cases i can check if it's working with?

limber wedge
# earnest gate my environment has `rustup` and `cargo`, but i've never been able to `cargo +[to...

Not sure I understand the issue 100% but the bevy linter at the moment requires you to have cargo installed via rustup: https://github.com/TheBevyFlock/bevy_cli/issues/194

GitHub
Linter: Support for running `cargo check` without toolchain proxy i...

Currently the build system for bevy_lint enforces a specific toolchain proxy via the +<channel> syntax in the cargo check command, assuming the use of rustup. This is incompatible with setups...

limber wedge
pale viper
#

I feel like it starts to add unnecessary complexity that could easily break, which makes it a lot harder to maintain in the future

#

I have no objection to adding Cargo aliases, though, so I wouldn't mind a cargo bless shortcut for cargo test --test ui -- --bless.

pale viper
#

It should return ~/.cargo/bin/cargo, but maybe yours is different

earnest gate
#

it's ~/.rustup/..toolchain../bin/

worn jetty
#

Are you planning to release a changelog for bevy_cli?

limber wedge
worn jetty
foggy basin
pale viper
#

If you need help with building the linter locally, just let me know :)

pale viper
earnest gate
#

for reference, i'm on a bare arch linux install with rustup via pacman and symlinks /usr/local/bin -> /home/gigamicro/.bin/ (unsafe ik) and /home/gigamicro/.bin/cargo -> /home/gigamicro/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/bin/cargo

pale viper
earnest gate
worn jetty
#

Is it planned to ship bevy_lint directly with bevy_cli in the future?

limber wedge
# worn jetty Is it planned to ship `bevy_lint` directly with `bevy_cli` in the future?

For me personally yes(in some sorts). Many lints are aimed to help beginners so it should be made as easy as possible to get the linter up and running. Its just not something that is currently planned for 0.2 or 0.3. (of the linter). I think we first need to figure out how we want to support different versions of bevy before tackling that issue.

limber wedge
foggy basin
#

Yes I suppose we can reuse that document!
Or add a new section about the prototype

limber wedge
#

sure will do!

foggy basin
#

Sorry I have been quite busy the last week

limber wedge
#

wrote / mostly copied some of the section from the readme so we have a basic overview in the hackmd

near mist
#

sorry for the delay, busy irl. did a first pass now :)

foggy basin
near mist
#

for example, overriding the default index.html provided by bevy CLI (e.g. user can pass --html path/to/index.html to bevy CLI, or else it'll look for a web/index.html or wasm/index.html, and if none of those are found, it'll use its own default index.html)

#

also i'd want there to be an easy way for a user to find out exactly what bevy run and bevy run web etc. do, so they can switch off bevy CLI for more control / flexibility

#

i haven't been keeping up much with bevy CLI development and a lot has happened, so these things might already exist

#

this isn't a hard blocker though, if we prefer to merge first and iterate later. there's time before the next bevy jam, which is when bevy_new_2d sees the most use

foggy basin
foggy basin
foggy basin
foggy basin
pale viper
#

Right now the CLI provides the bevy lint command, which is a shortcut for calling the bevy_lint executable if it is installed

#

In the future I think it would be great if the CLI supported installing the linter for you, but I think it might be really difficult to install them both at the same time

#

Who knows, though! I’d be happy if it turns out to be possible :)

lapis fjord
#

So, I tried installing the linter, but when I invoke it, it complains of a missing dll

foggy basin
pale viper
lapis fjord
#

I did

limber wedge
pale viper
# lapis fjord I did

Could you share what error message you're receiving? I'm assuming you're on Windows

lapis fjord
#

Will do when I get home

pale viper
lapis fjord
#

Plus a popup window complaining about a rustc-driver-<jibberish>.dll being missing

pale viper
lapis fjord
#

Thanks 😄

limber wedge
#

@pale viper if you have time and feel like it feel free to add / fix the missing lints: https://github.com/TheBevyFlock/bevy_cli/pull/263 since its one of the last few open issues for 0.2.0. i just started once and will try to finish it this weekend.

GitHub
Handle macros in lints by DaAlbrecht · Pull Request #263 · TheBevyF...

Closes #167

borrowed_reborrowable
insert_event_resource
insert_unit_bundle -> Check if the span of the "spawn" method call is from an external crate
main_return_withou...

pale viper
#

I'm just about finished with reviewing the Cargo lint infrastructure in #185, so I'm hoping to wrap that up by the end of today

#

I may remove #263 (the macro one) from the v0.2.0 release milestone, since Cargo lints and the Windows issue are higher priority for me, but I'll let you know

#

For now, I'm still hopeful I can get it reviewed before the end of February, since that's my hard-deadline for v0.2.0 :)

limber wedge
pale viper
#

Hah, I try my best! Thankfully we don't have too many (if any) users at this point, so any pressure I put on myself is purely artificial

#

Reviewing is not my strong suit, but it's the least I can do considering the time you take to help :)

limber wedge
limber wedge
molten merlin
#

Is there a list of the available bevy_lints somewhere?

pale viper
#

There’s a few other things on the website as well that you may find useful :)

molten merlin
#

ah nice, this should get linked prominently in the README I think 🙂

#

ah ok, it seems like panicking_methods can not be specified in a Cargo.toml (but the sub-rule panicking_query_methods can)

[package.metadata.bevy_lint]
missing_reflect = "warn"
panicking_methods = "deny"

warning[E0602]: unknown lint: `bevy::panicking_methods`
  |
  = help: did you mean: `bevy::panicking_query_methods`
  = note: requested on the command line with `-D bevy::panicking_methods`
  = note: `#[warn(unknown_lints)]` on by default
pale viper
#

I opened issues for both of those points, thank you!

worn jetty
#

Can we adjust the first step of bevy build to be opt-in (via --autoinstall flag or something) and make the default behaviour throwing useful error messages?

Auto installing on behalf of the user is not an acceptable default imo.

#

e.g. I don't even have rustup installed and the command wouldn't work for me at all

limber wedge
foggy basin
# worn jetty e.g. I don't even have rustup installed and the command wouldn't work for me at ...

While we don't install anything without asking the user, it's true that the command currently won't work without rustup.
For the first prototype, it was an easy way to detect if the wasm target is installed.
Can you share more info about your setup to check what we can work with instead?

I assume we will later change the command to be optimistic and not perform the check beforehand, instead parsing the error output for the related error messages and only then asking the user if we should install the target via rustup

#

As a first step, we can add a simple check whether rustup is installed and then just skip the wasm target check.
You will still need to ensure that the target is installed, but then at least you're not completely blocked from using the prototype

limber wedge
limber wedge
#

Our „own“ NeedlessPassByValue lint would be pretty cool. I really like that lint usually but in a bevy project it has so many false positives that we could hardcode skip the lint for.

pale viper
foggy basin
#

I updated the CLI 0.1.0 milestone with a few more tasks to avoid regressions on bevy_new_2d.
Work is currently more stressful so I have less time/motivation to work on this, but I'll keep chipping them away over time.
It might delay the release a bit, but I'd rather have all stakeholders 100% on board with the CLI than rush it through for a release

GitHub
`bevy_cli` 0.1.0 Milestone · TheBevyFlock/bevy_cli

A Bevy CLI tool and linter. Contribute to TheBevyFlock/bevy_cli development by creating an account on GitHub.

pale viper
#

Hi everyone! It's been a hectic (for me, anyways!) past few days, so I figured I'd recount what I've been working on and what the current plan is for the linter.

#

First up, I finally finished reviewing #185, @limber wedge's duplicate_bevy_dependencies Cargo lint. (And he's already addressed the changes! 😆) The current plan is to merge it with a few rough corners under the nursery lint group, so people can experiment with it

#

Second, I opened #276, which is a specification for lint module docs. This should hopefully make it clearer what I look for in documentation, and help keep things consistent

#

I also opened #278 today, which updates clippy_utils, our nightly Rust toolchain, and bevy_lint to Rust 2024! By pure happenstance, it fixes #252 (the pesky bug where zst_query would ICE, forcing that lint to be moved to nursery)

#

Unfortunately zst_query cannot be moved back to restriction (or another lint group) because I found a fundamental flaw with it while testing, as documented in #279. It still has a bit more work to be done, since it turns out the data yielded by Query<T>s doesn't have to be T, but can be anything depending on T's QueryData implementation

#

In other news, I also reviewed and merged #271 (our first breaking change!) yesterday and triaged #277 today

#

Looking back at the v0.2.0 milestone, we're largely on pace. While technically behind the soft deadline, we still have 1 full week before March, which is the hard deadline where the linter will be released no matter what

#

I'm confident duplicate_bevy_dependencies in #185 will be merged by then. #167 is lower priority, so if it doesn't make the release than that's fine, though we do have an open PR for it.

#

#267 is a problem, though, because I'm pretty sure it breaks the linter entirely for Windows. I need to do more testing, but I believe something about rustup run isn't setting up the PATH correctly for bevy_lint_driver, causing it to fail to discover rustc_driver.dll

#

This is something that probably will block the release, since it likely needs to be fixed before the linter can be incorporated into Bevy's CI (which is the overall goal of this release). If I continue making no progress, I'll try pulling in one of my friends who is more familiar with MSVC and the distilled chaos that is Windows

#

So that's all! I hope this sheds some light on what I've been working on, and where the linter stands currently :)

worn jetty
#

Why exactly are we relying on rustup within the bevy_lint crate, btw? I just want to understand /gen

#

As far as I can tell the reasoning goes:

  • you need rust nightly to hook into the compiler features
  • rust nightly is too unstable so you pin specific versions of it
  • you need to ensure users have that specific version, so you put it in the rust-toolchain.toml and install it in build.rs
  • in bevy lint you explicitly call that toolchain via rustup

Is that correct?

limber wedge
limber wedge
limber wedge
worn jetty
#

I see, thanks! I'll give that some more thought. Maybe we can just tear that all out and replace it by instructive error messages instead of doing so many things on behalf of the user? Not sure

pale viper
pale viper
limber wedge
#

Is the „allow maintainers to push directly“ or however this option is called on a pr more annoying than helpful?

pale viper
limber wedge
#

Im sorry ^^ will take it out from now

pale viper
#

It's not your fault! I tried using git push -f, which looking back was not the right decision

#

I may have broken your main branch, so you may need to regenerate it on your fork

limber wedge
#

No worried im gonna throw away that anyway. Working on main on a forked repo seems not a good choice

#

Rather keep my main in sync and branch off. Makes merging into my pr‘s easier

pale viper
#

Yeah. In the future, I'll stick to Github's review suggestion UI for making changes instead of trying to push changes from my computer

#

Seems a lot safer at the moment bavy

limber wedge
pale viper
#

I've never used anything other than Github, so I wouldn't know

#

This must be how people who've only used Java Gradle feel

foggy basin
pale viper
#

@limber wedge invite sent :)

#

Now instead of working on a fork, you can create branches on the repo itself. You can also merge PRs, but please make sure they have 1 approval first

limber wedge
foggy basin
limber wedge
#

we should also revisit the CLI e2e tests so we can lower ci time a bit ferris_sob

foggy basin
#

I'm also thinking about using the CLi version of wasm-opt instead of bundling it directly. It would be a bit less reliable/configurable, but the compile times are quite harsh

limber wedge
foggy basin
#

But 45 min sounds suspiciously like wasm-opt.
I think using the CLI version will be the way to go, then we can use cargo binstall to install a pre-compiled version and save a lot of time

#

I think trunk also uses wasm-opt, we can also check how they handle it

limber wedge
pale viper
foggy basin
pale viper
limber wedge
foggy basin
#

@pale viper Didn't you create a PR to read linter settings from Cargo.toml?
I want to use it as reference to do the same for the main CLI, but I can't find it anymore

#

Should we create a third crate that we can use in both bevy_cli and bevy_lint?
I feel like we're slowly duplicating more and more small pieces of code

pale viper
pale viper
#

As you work on CLI config, for now just copy-and-paste what you need. If it ends up being a large chunk, then I'd be willing to consider it further!

limber wedge
rocky oxide
#

I don't think anyone is going to be using the CLI on no_std hardware TBH

pale viper
#

The A Maintainer Has Spoken

rocky oxide
#

A maintainer has spoken :p

pale viper
#

Hah, good correction, though none of the others peak into this channel :)

#

As a side note to @limber wedge and @foggy basin, I've switched back on the requirement for a maintainer approval before merging

limber wedge
pale viper
#

Question: does anyone object to me deleting the X-Uncontroversial label? It seems pretty pointless, since uncontroversial issues don't need a label in the first place

#

I've been going through the lint list and our issue backlog, labeling things, which is why I'm bringing this up

rocky oxide
#

Might be less important here

trail shale
#

||also proof that I peak into this channel||

#

||just, not usefully||

pale viper
foggy basin
foggy basin
foggy basin
foggy basin
limber wedge
#

You are on fire!super_bevy

worn jetty
limber wedge
#

o "System.IO.IOException: No space left on device : '/home/runner/runners/2.322.0/_diag/Worker_20250226-195434-utc.log'"

trail shale
#

well a quick guess would be that there's no space left on the runner drive 😄

#

you only have 14GB available

limber wedge
trail shale
#

seems cache is messed up on the repo. probably not the only issue, but the caching story is bad

limber wedge
foggy basin
#

It should be cleared with cargo sweep, but who knows...

#

Us using two caches in the tests might also be problematic

pale viper
#

So that's 4 GB out of the bat that are taken up per run

#

They also cache the same things twice (in the ~/.cargo folder), so that may be causing issues

#

I'm going to delete our entire cache and see if that does anything

limber wedge
#

Thanks!

#

I only moved the E2E tests into the tests directory because it looks kind of weird otherwise but if it makes caching that much more complicated we can just move it back again?

trail shale
#

and with the volume of cache generated github deletes everything older than 1 day

pale viper
#

Sharing a cache between jobs could help with caches not being shared across branches, however

#

I opened #291 to decrease CI times (and hopefully cache sizes as well). Once the checks finish running, it should be ready to review

pale viper
#

Heck yeah, check out these improvements!

image.png
limber wedge
pale viper
#

CI was one of the first things that I contributed to in Bevy, so it's great to roll back my sleeves and hack it again

#

Just ignore the diff size 😅

#

(Though, honestly, cutting out ~16,000 lines of code is probably a good thing)

limber wedge
pale viper
#

Out of curiosity, what got you interested in Bevy / this working group?

limber wedge
limber wedge
#

And the fact that bevy does not yet have an editor was a big plus. As someone who has no idea about game dev they are often kinda overwhelming and i just wanna hack

#

How about you?

#

And for the linter i just really enjoy these kind of problems

pale viper
#

I first heard about Bevy back when 0.12 was released (back when I was still learning Rust). As I dug a little deeper, I got a strong impression that Bevy was the forefront of game dev in the Rust ecosystem

#

The other engines at that time, like Piston and Amethyst, were unmaintained, but Bevy was growing and crazy enough that it even found a few bugs in the Rust compiler

#

I started seriously contributing a year ago, and I've been here ever since! :)

limber wedge
#

Do you also work with rust at your job or only for fun on the side?

pale viper
#

Oh, I must have never mentioned this before

#

I don't have a job, I'm ______ :)

limber wedge
#

I knew you had some exam stuff

rocky oxide
pale viper
#

Hah, no! I'm still __

limber wedge
limber wedge
pale viper
#

Yeah, it's been a wild ride honestly

limber wedge
#

But you have a whiteboard that counts for at least 3 extra years

pale viper
#

lol totally! (Speaking of which, I should go update that...)

#

Once v0.2.0 of the linter is released, I plan to switch gears back to working on benchmarking Bevy

limber wedge
pale viper
#

Yeah, I'm seriously impressed by how quickly you learned. Hacking on the Rust compiler is hard stuff

limber wedge
#

Thanks still a long way to go but helps a lot that you take documentation very seriously

vast vine
lusty galleon
#

Sort of curious about the decision to use actix over axum or straight up hyper. But I haven't really paid attention to rust web backend stuff in a few years.

pale viper
#

I did notice that we're pulling in hyper anyways due to reqwest, so it may be worth dropping actix_web anyways in favor of that (axum)

pale viper
#

Bevy as a lot of extra features that we don't really need in testing

#

The other thing I did was go through our direct dependencies and disable features that I thought we wouldn't need

#

So that PR wasn't any special trick like more caching, just pruning some extra things that we don't actually need

trail shale
lusty galleon
pale viper
#

Thanks for mentioning it anyways, though, since we can probably switch to axum to decrease build times further

foggy basin
foggy basin
foggy basin
sturdy tapir
#

idk if we are linting for this but ran into a tiny error i was confused by.
Do you spot the REAL mistake?
Awnser: ||When I cloned the transform to pass it as a component clippy told me it was a "needless clone", but i technically was needed or rather a deref was needed. In short, that transform is a &Transform this had the unintended consequence of making it a invalid tuple bundle.||

image.png SPOILER_image.png SPOILER_image.png
#

dont think its something bevy can fix, only could lint against it

pale viper
sturdy tapir
#

then sure

pale viper
#

Wait, no! I meant adding that impl block to bevy_ecs, not the linter! 😅

#

Like what if instead of Bevy failing to compile, it just copied transform for you

sturdy tapir
#

idk def an ecs question lol

pale viper
#

Fair enough

#

I do think it would be troublesome to make that a lint, however, because its already an existing compile error

#

Afaik, lints are run after type checking, trait checking, and other bits of analysis. If one of those raises an error, I don't know if the lints would even run

#

It may be possible to override the compiler query that does type checking, but that sounds....... scary

molten merlin
pale viper
#

I opened an issue for switching to axum with some guidelines on how to achieve it :)

molten merlin
foggy basin
limber wedge
rocky oxide
#

I'd love a hit list.

#

I think that we're probably going to leave in World::resource and friends for now, so it'll probably stick around, just as a less important lint

limber wedge
rocky oxide
limber wedge
rocky oxide
#

Okay, that's an easy PR

#

definitely cutting that

pale viper
pale viper
#

(I'm a little sad, because I did like that lint code, but yay for better ergonomics!)

limber wedge
foggy basin
foggy basin
#

Just another day as Bevy contributor:

> cargo clean-recursive
Total space saved: 152.3 GB
limber wedge
pale viper
#

If you all have time, would you mind looking over this draft blog post announcing v0.2.0 of bevy_lint?

#

cc @rocky oxide, since I appreciate your writing ability, but no pressure if you don't have the time :)

versed sparrow
limber wedge
sturdy tapir
#

TIL the require attribute must be below the derive component attribute or else it wont work, nor will any errors be thrown till you make assumptions about it working...

pale viper
#

If it compiles, we could definitely write a lint for it

sturdy tapir
pale viper
#

Weird! Would you mind opening an issue for this? It sounds like a useful lint!

#

@limber wedge this might be our first early lint pass! :D

sturdy tapir
limber wedge
#

ferris_spooky would be cool!

limber wedge
#

I dont really see the benefit of a Component or Resource (and similar) command since i don’t create a file per component. For the plugin one i could see this more as a potential future feature that could integrate with a bevy editor.

sturdy tapir
#

Plugin is only one that would be useful imo
Component/resource/state/event all fall under "let the user do it" imho

lusty galleon
#

lint idea: reading/writing files in normal systems, not in an async task

foggy basin
#

Currently thinking about how to best implement the feature configuration in Bevy CLI. The main motivation is that you often need to enable different sets of features in dev vs. release or native vs. web and it's a hassle to do it manually.

Option 1: Custom CLI config in Cargo.toml, e.g.

[package.metadata.bevy_cli.dev]
features = ["bevy/dynamic_linking", "bevy/bevy_dev_tools"]

[package.metadata.bevy_cli.native.dev]
features = ["bevy/file_watcher", "bevy/embedded_watcher"]

[package.metadata.bevy_cli.web]
default-features = false

Option 2: "Magic" feature flags that are enabled automatically, e.g.

[features]
default_dev = ["bevy/dynamic_linking", "bevy/bevy_dev_tools"]
default_native_dev = ["bevy/file_watcher", "bevy/embedded_watcher"]
# No `default-features = false` for the specific profiles possible

I wrote down some advantages/disadvantages in the GitHub issue.
Currently leaning towards option 2.

Any opinions?

GitHub
Add configuration to automatically disable/enable features when run...

We should provide an option to automatically disable default features and enable features when running the app on the web. For example, via a package.metadata.bevy_cli.web.default-features = false ...

limber wedge
# foggy basin Currently thinking about how to best implement the feature configuration in Bevy...

a bit sad cargo does not support defining features in custom profiles. I don't have a strong opinion but im often not a fan of "magic" and while Option 1 is some CLI specific configuration migrating away or to a custom solution is very very simple. And to me i think if we would in the future then have some configuration fields under [package.metadata.bevy_cli it would be weird that the features are not there.

limber wedge
#

@foggy basin https://github.com/TheBevyFlock/bevy_cli/issues/289 I had some thoughts:

  1. Does the wasm-opt version need to match another version we install (like wasm-bindgen) is there a "minimal required version"?
  2. I found this rust wasm-opt cli wrapper https://github.com/brson/wasm-opt-rs but it seems unmaintained. So I would rather not depend on that, so do we want to install directly from https://github.com/WebAssembly/binaryen/releases via wget? Or what would be the best method so we don't need to also check if our "installing" method is installed (Not familiar with Windows but iirc it was only available in Powershell by default)^^. Not sure if this is worth it
near mist
foggy basin
limber wedge
earnest gate
#

possible lint, Query<Children>.find(|ch|ch.contains(e))

sturdy tapir
earnest gate
#

should use a parent instead of finding the entity containing a child
either Query<&Parent>.get(e) or editing the source of e to get a Parent

hexed jacinth
# 
D:\Rust Projects
❯ bevy new proj
Error: error sending request for url (https://api.github.com/orgs/TheBevyFlock/repos)

Caused by:
    0: client error (Connect)
    1: invalid URL, scheme is not http

I have a sneaking suspicion I've done something wrong squints

limber wedge
hexed jacinth
#

Opened 8 minutes ago
That explains why I didn't find it ferris_sob

#

installed the version on the PR and it worked perfectly 🎉

limber wedge
#

Ha! CI passes on windows but not macos while i use macos, usually its always the other way around ferris_spooky

pale viper
#

It's why in the engine's main CI we use MacOS in a larger amount of places, even though Linux is considered the "default"

#

👍

limber wedge
pale viper
#

<@&1064695155975803020> bevy_lint v0.2.0 is ready to be released. As per the release process, we need the approval of at least one maintainer before it can be published! If any have the time, I would appreciate them stopping by #308 to leave their review. Thank you!

foggy basin
#

Just saw that cargo metadata output also contains the workspace and package metadata, so parsing the Cargo.toml manually shouldn't be necessary

lapis scroll
#

If not, I think I’ll try to work on it

rocky oxide
limber wedge
rocky oxide
#

Mildly evil idea that is relevant to this group's interests

pale viper
#

Once #![register_tool(...)] stabilizes, that should make the linter much easier to use :)

quick kayak
#

yay!

#

my favorite part of working on stuff like this is hearing how people plan to use it

pale viper
#

Hi! I didn't realize you were on this server :)

quick kayak
#

i wasn’t until 5 minutes ago ^^

#

alice invited me

pale viper
#

If you didn't see my message on Github, I'd love to help with the RFC

quick kayak
#

ooo

pale viper
#

I'm not quite familiar with the process, and need to research path resolution a bit more, but willing to learn!

quick kayak
#

let me type up what i know so far. the main remaining steps are

  • wait for the crate-attr rfc to land
  • read through ~150 comments on the register_tool tracking issue, and the original rfc that only addressed official tools
  • write it all up

additionally i’ve been getting feedback in dms on how people are using it and i need to make a brain dump of that

quick kayak
#

also though i don't want to spend too much time on this because cough i was going to use it to reward myself for making progress on apartment hunting lmao

pale viper
#

Hah, that sounds good!

#

I think the biggest "hard problems" is how a registered tool's name may conflict with existing names (source) and whether lint registration and attribute registration should be separate (source)

quick kayak
pale viper
quick kayak
#

lccc is vaporware

#

marker looks dead, last commit is 2 years ago

#

dylint is a modern version of that

pale viper
#

Right! I remember reading one of their blog posts when I first got started

quick kayak
pale viper
#

I think they work around #![register_tool(...)] being unstable by just not using lint namespaces at all

quick kayak
#

oh fascinating

#

#[allow(unknown_lints)]
lol yeah

#

i should chat with them

pale viper
#

I think smoelius would be a good person to reach out to about this

quick kayak
#

i am very interested in what they think about namespacing, whether there should be a dylint namespace or a namespace for each tool using the library, and if the latter whether they think it should be valid to have a crate name and tool name overlap

pale viper
#

Yeah totally! I think it would be nice for Dylint to expose that option to lint authors too

quick kayak
pale viper
#

I started with Dylint, but moved away after trying it for a while

#

I don't think I was a fan of the installation process required when using Dylint

quick kayak
#

yeahhh being a rustc_driver is so hard

#

i want to make it easier but i'm not sure where to start

pale viper
#

I think it was because I wanted bevy_lint to be usable as its own standalone tool (like Clippy), while Dylint is more targeted towards composing multiple linters together

quick kayak
#

(well i guess i do, i'm starting with register_tool lol)

pale viper
quick kayak
#

oh interesting

#

cargo semver-checks can almost certainly do that

pale viper
#

It's been smooth so far upgrading which nightly version bevy_lint uses, since usually I just have to fix compile failures

#

I always worry that I'm missing some behavioral change, though, that the compiler wouldn't catch

pale viper
quick kayak
quick kayak
#

the driver is the simplest part, trustfall doesn't care about your compiler version

#

why don't i invite you to the CSC discord?

pale viper
#

Ah, cool! I get that rustc_driver has no guarantees about stability, but still I'd like to know if things break

#

Honestly, a link to a PR is enough at this point ^^

pale viper
quick kayak
pale viper
#

Thanks, I'm in!

pale viper
quick kayak
#

oh jeez

pale viper
#

And unfortunately it doesn't work anymore due to a CORS issue that I wasn't able to fix 🤷‍♂️

quick kayak
#

this tool is fascinating because it's simultaneously too much and too little info lol

#

it shows you every modified line but it doesn't know which ones are important

rigid bluff
#

Maybe it's a dumb idea but would integrating profiling into the cli make sense ? Like an easy command to run and profile the game without the hassle of setting stuff up ?

rocky oxide
limber wedge
sturdy tapir
rocky oxide
rocky oxide
pale viper
#

I'm going to wait to do that until after v0.2.0 releases, however, since we're so late in the process

pale viper
#

I’m working on publishing v0.2.0 now! If you all could avoid merging any PRs for the next few hours, I would really appreciate it!

pale viper
#

A few hours late, but v0.2.0 is published! The announcement post is also up, with some fun little features I enjoyed putting together :)

rocky oxide
limber wedge
pale viper
#

I saw you were working on the macos-runner-ci branch, did you figure out what was going wrong?

limber wedge
#

not yet, im just trying out different things on that branch. I added (and removed alread) some rerty logic but it seems that either it works first try or never.

pale viper
#

Wait, nevermind. That commit simply merges the bevy new tests 🤦‍♂️

limber wedge
#

yea ^^

#

I think i will add some logs next to see where the timeout happens but im sadly sick so not sure when i get to it sorry

#

Its a pretty annoying issue ferris_sob

pale viper
#

Weirdly enough, I haven't been able to reproduce the issue locally on MacOS. I fear it's some runner-specific issue

limber wedge
quick kayak
#

oh god there were multiple tool attribute rfcs

#

hold on i am collecting a list of relevant links

#

oh no

#

oh god

#

so it turns out that you don't actually need a feature gate if instead of doing #[bevy_cli::foo] you do #[clippy::bevy_cli::foo] instead

#

i don't like this

quick kayak
#

clippy doesn't even warn jeez

quick kayak
#

i need to read the rest of the backlinks on the tracking issue, the original tool attribute RFC that was meant only for rustfmt, and the tracking issue for "tool attributes" (which makes no sense for me; it should surely be part of the tracking issue for register_tool)

#

a lot of people want to use this, more than i expected

quick kayak
#

@pale viper out of curiosity: why did you choose bevy_cli:: as the prefix for lints instead of bevy::?

#

(i suspect the answer is "the latter is disallowed right now" but i just want to confirm)

pale viper
quick kayak
#

oh cute

#

wait doesn't that error if you already have the bevy crate in scope?

#

wait no that's only attributes, not lints

#

i confused myself again

#

oh jesus this is legal

#[rustfmt::arbitrary::number::of::segments(then * arbitrary !!! token ~~~ tree ^_^)]

#

and stable

#

ugh

#

oh ok it's caught by rustfmt

#

yeah ok that's the right semantics

#

fascinating, extern crate rustfmt seems to be legal

#

even extern crate log as rustfmt

#

i think tool attributes need a bunch more documentation honestly

#

let me finish reading through these issues and i'll send what i have written up so far

#

lol let me fix discord's highlighting

#

oh it's just broken cool

#

anyway

#

@pale viper the next steps are:

  1. document how tool attributes work today
  2. document how register_tool works
  3. collect a list of how people want to use this (not projects, use cases. so for example "i want my proc macro to have custom lints" would be a use case)
  4. write up a thread on IRLO making sure that step 3 is complete
  5. write an RFC
#

let me know which if any of those steps you are interested in

quick kayak
quick kayak
quick kayak
sturdy tapir
#

bevy_cli has project creation correct?

limber wedge
sturdy tapir
#

i want to just use it for project managment rather than the editor reimplment it

#

aka editor launcher just acts as a ui for the cli a little

limber wedge
#

Yea 1000 would be my vision too but not sure what the official plan is

rocky oxide
sturdy tapir
limber wedge
pale viper
trail shale
#

do you know the error it gives? github has a low~ish rate limit when calling github apis from github actions if you don't give a token

limber wedge
#

Iirc it just times out but maybe before closing we can try to clone with a token

pale viper
pale viper
trail shale
#

hum "silently fails" is a bug on the side of the CLI, it should raise the proper error

#

you're ? all the way to main, that's not proper error handling 😄

pale viper
#

Fair enough, we definitely should add .context() in places to annotate the errors

#

It may be worth setting RUST_BACKTRACE=1 in CI too

limber wedge
#

oh yea it is the rate limit stdout: Ok(Response { url: "https://api.github.com/orgs/TheBevyFlock/repos", status: 403, headers: {"date": "Mon, 24 Mar 2025 15:59:08 GMT", "server": "Varnish", "strict-transport-security": "max-age=31536000; includeSubdomains; preload", "x-content-type-options": "nosniff", "x-frame-options": "deny", "x-xss-protection": "1; mode=block", "content-security-policy": "default-src 'none'; style-src 'unsafe-inline'", "access-control-allow-origin": "*", "access-control-expose-headers": "ETag, Link, Location, Retry-After, X-GitHub-OTP, X-RateLimit-Limit, X-RateLimit-Remaining, X-RateLimit-Reset, X-RateLimit-Used, X-RateLimit-Resource, X-OAuth-Scopes, X-Accepted-OAuth-Scopes, X-Poll-Interval, X-GitHub-Media-Type, Deprecation, Sunset", "content-type": "application/json; charset=utf-8", "referrer-policy": "origin-when-cross-origin, strict-origin-when-cross-origin", "x-github-media-type": "github.v3; format=json", "x-ratelimit-limit": "60", "x-ratelimit-remaining": "0", "x-ratelimit-reset": "1742832588", "x-ratelimit-re

#

Thanks for the hint!!

pale viper
#

If you need any help, let me know :)

limber wedge
pale viper
#

I also took a look at the HackMD you sent out: how do you think registered tool namespaces should cooperate with imported modules when it comes to attributes?

# 
#![register_tool(foo)]
extern crate foo;

#[foo::bar]
fn main() {
  // ...
}
#

Which foo takes precedence in this scenario? Should a warning / error be emitted?

quick kayak
#

i think this actually matches people’s expectations tbh. you don’t expect extern crate rustfmt to break rustfmt::skip

#

(it does today! i think that’s bad.)

quick kayak
# pale viper Hey, sorry for taking a second to get back to you! I'm mostly interested in step...

cool. i am going to finish up https://github.com/rust-lang/reference/pull/1765 and the corresponding test pr. then i want to write up 4-5 edge cases and how i think they should behave. then i'll turn it over to you to write the actual rfc. sound good?

GitHub
Document the order preludes are resolved by jyn514 · Pull Request...

Also document the derive macro sub-namespace; apparently it was missing before.
cc rust-lang/rust#66079 (comment), rust-lang/rust#138840

#

ugh let me make a list of all the open source things i'm working on it's getting hard for me to keep track lol

#

i think i have a problem lol

image.png
pale viper
desert gale
#

EDIT: Fixed, the issue was the 2d template code using canvas: Some("#bevy".to_string()), removing this line and deleting the whole web folder seemed to make it work. Not sure why it didnt work without these changes though...

(apologies if this is the wrong place to ask this)

Im trying out bevy_cli and attempting to use the web feature, but am getting a few errors in chrome console:

Cannot find element: #bevy.
Unable to find a GPU! Make sure you have installed required drivers! (im on an M1 mac)

I have a fresh bevy project that i created using bevy new my-project -t 2d and i ran bevy run web --open

I see the loading spinner going indefinitely

limber wedge
# desert gale EDIT: Fixed, the issue was the 2d template code using `canvas: Some("#bevy".to_s...

Hi! this is absolutely the right place to ask and thanks for testing the bevy cli!. There is still some open work to port the https://github.com/TheBevyFlock/bevy_new_2d template to the cli. Mainly see: https://github.com/TheBevyFlock/bevy_new_2d/pull/312.

GitHub
GitHub - TheBevyFlock/bevy_new_2d: This template is a great way to ...

This template is a great way to get started on a new 2D Bevy game! - TheBevyFlock/bevy_new_2d

GitHub
Build software better, together

GitHub is where people build software. More than 150 million people use GitHub to discover, fork, and contribute to over 420 million projects.

#

oh, glad you got it to work! yea thats what this PR would change ^^

desert gale
#

thank you! Having a great time with it so far, thank you all for the work on it. Just getting back into Bevy after a long break, so this was super helpful to get started on a new project without any hassle/recalling how things work. 🙂

thanks for the links, ill take a look!

near mist
#

should probably try to get the integration working before the upcoming bevy jam

#

the PR is mergeable as is iirc, there were just some things on the bevy CLI side that could be improved to not regress some minor things on the bevy_new_2d side

#

some (all?) of which have been fixed

rocky oxide
#

Right yeah: I hope we can get folks to dogfood this for the upcoming jam

pale viper
near mist
#

my potential concerns would be wrt false positives and CI time / space (especially for private repos)

#

i expect the latter to not be a big deal though, it's more of a thing for the release workflow

#

@foggy basin, is the PR to switch from trunk to bevy run web unblocked now?

near mist
limber wedge
#

@pale viper Before we can add it to the template we need to support bevy 0.16.0 since the jam will be using that version i assume? If so i went quickly through our paths: https://github.com/TheBevyFlock/bevy_cli/blob/298-bevy-v16/bevy_lint/src/paths.rs

  1. EntityCommands changed, we need to check what this means for us
  2. Resource changed only the path i think.
  3. Remove the variants that no longer panic from the panicking_methods lint

And then we should be good to go! I have lots of time tomorrow and on the weekend so i will get a PR going, but i think i would like some help with the EntityCommands change.

GitHub
bevy_cli/bevy_lint/src/paths.rs at 298-bevy-v16 · TheBevyFlock/bev...

A Bevy CLI tool and linter. Contribute to TheBevyFlock/bevy_cli development by creating an account on GitHub.

foggy basin
pale viper
#

Also, I like the change you made where you added comments linking to the source definitions! In the future, we may be able to even make a test that verifies those paths exist :)

limber wedge
pale viper
#

Clippy and rustc have the concept of internal lints, lints behind a #[cfg(feature = "internal")] flag, that are used to check themselves. We could use that to verify all paths in paths.rs exist

#

Anyways, with the upgrade to 0.16, do you think we should make a new release as bevy_lintv0.3.0, or simply install the specific commit in CI?

pale viper
limber wedge
pale viper
#

Maybe v0.3.0-rc.1? An unstable release candidate specifically for the game jam?

limber wedge
#

We could change the milestone to only include the v16, macro and panicking issue and then release it end of this week?

#

Or even exclude the macro pr though we could take it in since its „ready“

limber wedge
near mist
foggy basin
limber wedge
#

@pale viper while the docs.rs page looks way nicer for the lints in regards of their LintGroup its kinda awkward that we need to move a file if we want to change the Group Maybe in the distant future it would in the end still be easier if we just have a separate page like clippy: https://rust-lang.github.io/rust-clippy/master/index.html

Clippy Lints

A collection of lints to catch common mistakes and improve your Rust code.

pale viper
#

Maybe, but I'm unsure how often a lint's group will change once it exits nursery. Maybe pedantic lints will be upgraded to suspicious, and maybe suspicious to correctness, but I don't know how much of an issue that may be

#

On the other hand, making a custom page like Clippy gives us a lot more flexibility and room to improve the experience, so I'm not against it

#

I originally used rustdoc for the lint documentation because it makes life a lot easier. All we have to do is put the docs next to the code, and rustdoc automatically handles parsing the Markdown, generating the website, and making it look pretty!

#

So while I'm not against making a custom website in the future, I'm not sure we should work on it right now, just because there are other things I think are more important :)

limber wedge
quick kayak
quick kayak
#

ok i think those two are mostly done

#

umm

#

let me write up the corner cases with register_tool

#

i think this is going to be my last rust project for a while

quick kayak
#

there are probably some i'm missing, i'll think about it later when i'm less tired

#

the module resolution one really worries me

#

i don't know what to do about that

near mist
#

setting type: shell with bevy run seems to work fine

#

however, bevy run itself has some extraneous output that cargo run does not, and i think it's undesirable

#

if there are errors, cargo run outputs the error messages to stderr and then exits with status code 101

#

bevy run then sees that its Command "failed" so it prints the error and exits

#

a user of bevy run doesn't need to know that the Command failed within bevy_cli's code, it's useless information unless you're trying to debug bevy_cli itself

#

also with RUST_BACKTRACE=1 enabled it includes a stack backtrace from within bevy_cli

limber wedge
quick kayak
#

please do read through the hackmd - happy to answer questions about anything in there, i know i was kinda writing in shorthand for most of it

limber wedge
limber wedge
pale viper
pale viper
#

Today I'm dedicating a couple of hours working on bevy_lint stuff! I have a fun checklist and everything 🦆

limber wedge
quick kayak
#

kwak

pale viper
#

Hah, that's the limit of my drawing ability :D

rocky oxide
pale viper
pale viper
#

We'll see how that goes :)

foggy basin
#

I'm currently working on the CLI features configuration and hope to get a PR ready some time today :)

pale viper
limber wedge
pale viper
sturdy tapir
#

Will the CLI only be published when its moved under bevy?

pale viper
sturdy tapir
limber wedge
#

The linter is. The cli did not yet release 0.1.0 but we are close!

foggy basin
limber wedge
limber wedge
pale viper
#

One of the things I really want is to make a semver::Version globally available so that we can easily check what version is being used anywhere within the linter (it's part of why the linter configuration is being stored in the static LINTER_CONFIG, even if it's never accessed)

#

For example, I want this:

if linter_config().version() > Version::new(0, 16, 1) {
  // ...
}
#

Another note: I have one more grand refactor in the works that converts LintGroup from a struct to a trait:

pub trait LintGroup {
    const NAME: &str;
    const LEVEL: Level;
    const LINTS: &[&Lint];
    fn register_lints(store: &mut LintStore);
    fn register_passes(store: &mut LintStore);
    fn register_group(store: &mut LintStore);
}
#

This would remove the need for BevyLint and the "Click me for more information" statics on each lint's page

#

My most recent thought was to handle version-conditional lint registration within each LintGroup's register_lints() method

#

Then again, I'm not sure which method is best in the long-run. This may require a design document to think through the constraints and requirements

limber wedge
limber wedge
#

I like the base idea of having the versions be some sort of structs so its easy to see what are the paths etc for this version as a maintainer but as a user we would like to easily see what lints are available (so like our current page as sub page based on each version)

near mist
#

it would be really nice to have cargo-binstall available for both bevy_lint and bevy_cli before the jam

#

so we don't have to have CI compile bevy_lint and release compile bevy_cli every time (especially for those using private repos with limited resources)

#

but i wouldn't call this a blocker

buoyant jasper
#

Hey folks! I have an issue and maybe some of you might know how to deal with it. I decided to give bevy-cli a go and I'm having this exact same issue when trying to build on CI: https://github.com/rustwasm/wasm-bindgen/issues/4422

Locally I don't have this issue, but in GitHub Actions I do. A snippet of what I'm doing here.

      - name: Install tools for WASM build
        run: cargo install --git https://github.com/TheBevyFlock/bevy_cli --locked bevy_cli

      - name: Build release
        run: RUSTFLAGS='--cfg getrandom_backend="wasm_js"' bevy build --yes $BUILD_PROFILE web --bundle

The error in the script is:
error: The "wasm_js" backend requires the wasm_jsfeature forgetrandom. For more information see: https://docs.rs/getrandom/#webassembly-support
Which is not the same error you get when you are missing the env var.

And on my Cargo.toml file I do:

[target.wasm32-unknown-unknown.dependencies]
getrandom = { version = "*", default-features = false, features = ["wasm_js"] }

I'll really appreciate your help!

pale viper
#

Also, make sure $BUILD_PROFILE is set elsewhere in the action! Usually you need env or environmental files

#

I would also test what happens if you move the getrandom dependency to be under normal dependencies:

[dependencies]
getrandom = { version = "*", default-features = false, features = ["wasm_js"] }
#

And maybe also set the version to >0.3.0! You never know :)

buoyant jasper
#

Already tried different ways to set the env var to no avail. The other var is working properly afaics.

I'll try setting the version like that just in case but I feel like it might be something else. I don't really understand what they meant in the solution proposed in issue I linked.

Thanks a lot! Any other ideas will be welcomed.

limber wedge
#

Hm im at work but can check when im home. I would perhaps test setting the rustflags in the .cargo/config.toml under the desired target. Not sure if it creates issues while installing wasm-bindgen-cli as hinted in the linked issue.

buoyant jasper
buoyant jasper
#

Some results:

move the getrandom dependency to be under normal dependencies
This is not possible, as the feature is wasm exclusive. This breaks desktop builds.

And maybe also set the version to >0.3.0!
No change with this sadly.

setting the rustflags in the Cargo.toml under the desired target
This didn't work for me even locally but now I'm not sure if I set it properly:

rustflags = ['--cfg', 'getrandom_backend="wasm_js"']

I'll keep trying later and if I find a solution I'll make sure I post it somewhere relevant.

limber wedge
#

Otherwise i assume you could also not use the cli to install the wasm-bindengen-cli and then set the rustflags as env variable

foggy basin
#

Speaking of CLI configuration, I think I got it working now for web builds.
Supporting native however might be trickier than I thought: To load the correct config, we need to know the package of the target we're building/running. To know that package (for certain), we need to execute cargo build/cargo run, but we need to pass the feature flags from the config to these commands!
On the web, we manually determine the target and have hence access to the package, but it doesn't have 100% the same behaviour as the target selection from cargo yet.
And ideally I'd like to keep full cargo compatibility at least for native builds.

Not sure yet how to proceed, maybe we ignore native for the first iteration, as supporting web-specific configuration would already solve a bulk of the issues

buoyant jasper
#

What ended up working was using . cargo/config file as suggested later. I was setting rustflags in my Cargo.toml file and that was incorrect. Thanks for your help!

limber wedge
foggy basin
buoyant jasper
#

I only wanted the bundling feature for web so it was quite useful but also simple to use for that purpose. But for what it's worth, it comes with pre-existing profiles that you can override, you don't really need an index file unless you do, has the "audio patch" built in... Pretty satisfactory if you ask me. I have yet to publish this bundle on itch.io so I might have other bits to share later.

quick kayak
pale viper
quick kayak
#

haha understood

#

no rush

foggy basin
limber wedge
pale viper
foggy basin
#

Opened a PR to allow setting custom headers for the web server: https://github.com/TheBevyFlock/bevy_cli/pull/343
This is for example required if you want to test out multi-threading on Wasm.
There are still several things to do before we can properly support that, but this is the first important step

limber wedge
#

You are on fire! super_bevy started reviewing the first pr but have to study a bit :( will for sure be done in the evening

foggy basin
#

No rush :)

limber wedge
#

I think on my mac i had problems with cargo install —path . on the branch but didnt get to check could just be that i have set a different version

foggy basin
#

Does it work if you install from the remote branch instead?

limber wedge
rigid bluff
#

Hello fine people of bevy_cli, I used to be able to use it without issue but recently it started doing that, any ideas ?

$ cargo install cargo-generate
    Updating crates.io index
     Ignored package `cargo-generate v0.23.2` is already installed, use --force to override
$ bevy new my_project -t 2d
Error:  Required cargo-generate version not met. Required: ^0.23  was: 0.22.1
near mist
limber wedge
near mist
#

ah right bevy_cli depends on the library version of cargo-generate

rigid bluff
limber wedge
#

yes and we just updated to 0.23 yesterday

rigid bluff
limber wedge
limber wedge
rigid bluff
limber wedge
#

I never really bothered with wasm but the web command makes it so nice i think you did such a good job! @foggy basin super_bevy

#

maybe the only downside is now i actually wanna support wasm lol

rigid bluff
#

Hello, does the cli support/plans to support easy exporting ? Like one command to export for windows that packs the zip with .exe and assets ?

foggy basin
foggy basin
rigid bluff
#

I think it would be pretty simple

molten merlin
#

as an end-user, versioning the template doesn't really make a whole lot of sense unless its going to get overridden when constructing a new template. My little test project or new game isn't 0.2.0, the template is. (this was generated via the minimal template)

[package]
name = "ecs-tilemap-16-test"
version = "0.2.0"
edition = "2021"
near mist
#

i have a draft pr waiting on bevy 0.16 that also changes the version back to 0.1.0, but that could be split out to merge it sooner

molten merlin
foggy basin
pale viper
foggy basin
#

I extended the design doc for the web functionality a bit. In particular, I added multi-threading and no_std/wasm32v1-none to the future work items.

#

I also want to mention that the bevy_cli v0.1.0 milestone is complete @pale viper @limber wedge.
I think the next step would be for the maintainers to review the current state and then for us to advertise the CLI more to invite broader testing?

near mist
#

and a binary release of v0.1.0 to github for cargo-binstall to pick up 🥺

limber wedge
foggy basin
limber wedge
#

It depends on the released binary name

foggy basin
#

I hope that it doesn't get confused because we have releases for both the linter and the CLI in the same repo

limber wedge
#

If tries to match the desired binary name with some patterns if it doesn’t match you can add annotations in the cargo.toml

foggy basin
#

Can we also use cargo-binstall to make it easier to use the linter?
IIRC it requires nightly and other configuration to be installed, is that still the case?
If yes, maybe we can configure all of that in CI and then allow the user to install the compiled binary

#

I guess that's something we can still prepare: Taking into account the maintainer's limited time and making it as easy as possible for them to test out the CLI :D

limber wedge
#

Yes still requires a specific nightly toolchain. I think we should be able to prepackage everything.

near mist
#

and apparently they try a few things before falling back on that

#

so it's probably "smart"

#

as for different binaries in the same github repo idk, but i'm sure there are other cases like that

foggy basin
foggy basin
#

I created a new PR which allows you to overwrite the web target and also set the default target in the config:
https://github.com/TheBevyFlock/bevy_cli/pull/355
This is especially important to target wasm32v1-none.
@old rover if you happen to have some time and a no_std project on hand, your testing would be highly appreciated!

old rover
foggy basin
old rover
#

Tested against this little dummy application:

#!/usr/bin/env cargo

//! \`\`\`cargo
//! [dependencies]
//! bevy = { version = "0.16.0-rc.3", default-features = false, features = ["web"] }
//! wasm-bindgen = { version = "0.2.100", default-features = false, features = ["msrv"] }
//! wee_alloc = "0.4.5"
//! \`\`\`

#![no_std]
#![no_main]

use bevy::prelude::*;
use wasm_bindgen::prelude::*;

#[global_allocator]
static ALLOC: wee_alloc::WeeAlloc = wee_alloc::WeeAlloc::INIT;

#[panic_handler]
fn suppress_panics(_: &core::panic::PanicInfo<'_>) -> ! {
    alert("Oh No!");
    loop {}
}

#[wasm_bindgen]
extern "C" {
    fn alert(s: &str);
}

#[wasm_bindgen]
pub extern "C" fn start() {
    App::new()
        .add_plugins(DefaultPlugins)
        .add_systems(Startup, || {
            alert("Starting Up...");
        })
        .run();
}
#

(the tripple-backticks in the cargo block wont format in discord lol)

foggy basin
old rover
#

frantically tries to fix formatting

foggy basin
pale viper
pale viper
limber wedge
earnest gate
#

i don't even use the cli, just the linter, and it was originally somewhat confusing to figure out where to get the installation instructions

pale viper
#

@quick kayak I've started working on the RFC at https://hackmd.io/@BD103/Hk8lGGj6R. I'm going to see if I can get a first draft finished in the next few days, but I'll let you know how things are going

#

I've invited you as an editor in case you have any comments / quick fixes you want to make, but no pressure :)

limber wedge
#

maybe i will take a bit longer with my pr's had some issues at work that needed to be fixed asap so i was busy working until 1am yesterday and the day before :(

foggy basin
#

I created a bigger PR which completely reworks our automatic installation process.
Instead of checking that the correct packages and targets are installed before every bevy invocation, the PR uses an optimistic approach and just tries to run the commands.
Only on failure, the checks are performed and the user is prompted to install missing dependencies if needed.
Afterwards, the CLI will retry the command and continue if possible.

This should (a) slightly reduce latency as less commands are executed on the happy path and (b) clean up the verbose logs to only contain commands that are really needed

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

pale viper
foggy basin
foggy basin
#

I guess I'll also start setting up a blog to be able to write a bit about the CLI development

pale viper
#

Oh and @limber wedge, do you want to see a really fun compiler bug? Check out 352190b and 918b79c

#

When the default level of a lint is specified by a constant, the UI tests fail, but when the level is behind a reference, the tests pass normally >:)

#

This was the bug that caused me to stop working on #341, since I had no idea what was going on. It was only until yesterday where I manually read through the HIR and MIR to see what was going on

limber wedge
#

I would have gone insane trying to find that out ^^

foggy basin
pale viper
#

I'm 80% sure it's a compiler bug, but I'm going to make a reproducible example before opening a bug report / trying to fix it

pale viper
#

Beware that if you use mdsvex for Markdown formatting, it uses a really old version of remark, so some plugins may not work. (I had to use a an old version of remark-footnotes, for example, for it to work correctly)

limber wedge
foggy basin
twilit dew
#

Hey, I just ran into a weird issue with bevy run web where the uuid crate didn't know which randomness backend to use

#

Dunno if this is a user error or not

#

Context:

#

Update: the described example now just loads forever in the browser :/

#

Chrome:

image.png
#

Firefox:

image.png
#

(the tab below are the dev tools that themselves seem to not load)

#

On another note: I'm using bevy run web for the Foxtrot rework, and it's working really really well there!

limber wedge
#

hm i think this part uuid = {version = "1", features = ["js"]} is expected. The example loads for me with bevy run -p map_loading web in chrome or safari.

twilit dew
#

Another thing: how do I run bevy run web with WebGPU?

#

I tried bevy run web -- --api webgpu but the CLI thinks that's an option for the web command

#

hmm actually even bevy run -- --api webgpu doesn't run

# 
error: unrecognized subcommand '--api'

Usage: bevy run [OPTIONS] [COMMAND]

For more information, try '--help'.
twilit dew
#

Another another thing: found a bug!
use bevy new -t 2d foo, and then add the following into the main.rs:

#[cfg(feature="dev_native")]
compile_error!("dev_native active");

cargo build will show the error, while bevy build will not. Somehow the default features got lost, even though that should only happen on release builds

limber wedge
twilit dew
#

Since that is not for web

#

(I know the feature though, it’s a really cool idea!)

limber wedge
#

O yea my dyslexic brain just thought you used the web command

twilit dew
limber wedge
#

Oh you are swiss too broovy

twilit dew
twilit dew
#

(assuming you're from the German speaking region)

limber wedge
#

Yes im from bern!

twilit dew
limber wedge
twilit dew
foggy basin
foggy basin
twilit dew
twilit dew
limber wedge
near mist
#

i have a friend who's learning bevy and trying out the bevy_new_2d template. however, the main branch of bevy_new_2d depends on bevy 0.16.0-rc.1, which is incompatible with most 3rd-party crates for now, so we wanted to use an older version of the template that depended on bevy 0.15

#

the bevy new command supports specifying a git branch, but not a tag or revision

#

i ended up creating a bevy-0.15 tag in bevy_new_2d and my friend had to use cargo generate to be able to specify the tag

#

so basically, feature request: support specifying git revision / tag in bevy new command :)

#

(also for some reason cargo generate with revision specified was not working, it couldn't find the revision from the SHA)

near mist
limber wedge
#

Good point! Thanks!

foggy basin
pale viper
#

@limber wedge would you like me to adopt the unconventional_naming PR? I've come down with a cold, so I have a bit of free time on my hands to work on it :)

limber wedge
#

I think i would like to finish it but if there is nothing else sure!

#

Oh and get well soon!

pale viper
#

Thanks! If that's the case, I'll work on something else

#

I think it's close to time to release v0.3.0-rc.0 of the linter, since Bevy 0.16 is super close to release

#

Additionally, I'm going to try to give the CLI the ability to install the linter (maybe bevy lint install or something)

limber wedge
#

I think if you enable cargo binstall the cli could use that?

#

And i think the lintgroup trait pr if unblocked would be pretty big too so we can start a design doc for how we want to support multiple versions

pale viper
#

I wish that were possible, but I'm pretty confident that the linter cannot be installed as a single standalone binary (which is a requirement for binstall)

limber wedge
pale viper
#

Yeah, unfortunately. I've looked it up, but I don't think it's possible to combine a dynamic library into an executable

limber wedge
#

I see yea then i guess having the cli setup the required rust toolchain would be nice

pale viper
limber wedge
foggy basin
#

@limber wedge The Rustflag PR looks good and works for me now, can you take a look at the merge conflicts when you have the time? :)

#

Once that's merged, I'll add the experimental multi-threading support. I think then we have all the necessary pieces in place

foggy basin
limber wedge
foggy basin
limber wedge
#

what is your guys opinion on this: https://github.com/TheBevyFlock/bevy_cli/issues/368 im not familiar with NixOS at all i personally just don't like having too many niche files in the root directory but if its the only way to support the nix folks then im okay with it.

GitHub
Add nix flake to allow Nix users to easily use bevy_cli · Issue #3...

I've done this in a fork of my own, but didn't want to submit a PR if this isn't something that is wanted in this crate. The nix flake adds a devshell for developers of the repo to use,...

twilit dew
limber wedge
pale viper
#

I like the idea of supporting Nix users, I just worry it won't be tested all that often

#

As far as I can tell, none of the frequent contributors drive Nix. If things break, they may stay broken for a while

#

I think I'm more interested in the Nix flake that lets users install the CLI easily, more so than the dev shell

#

But I will admit I'm quite uneducated on Nix as a whole

limber wedge
#

im all for supporting Nix on a "best effort" basis don't get me wrong we would just depend a lot on nix folks to test / find / fix bugs

pale viper
#

I definitely agree on the "best effort" part though. We should document it, though, so people understand they may run into issues :)

#

Although whatever support we add will certainly be better than our current state of affairs 😆

limber wedge
foggy basin
foggy basin
trail shale
foggy basin
#

@limber wedge @pale viper are there any more blockers before we can get the prototype reviewed by the maintainers?
If not we can start drafting a quick start introduction for them

#

We probably won't make it in time for the 0.16 release, but maybe it could make sense to do the announcement together with the Bevy jam announcement (given that there are no major objections).
That would also be a perfect opportunity to try out the CLI and it should provide a lot of benefit given how important a web build is for jams

limber wedge
pale viper
#

The installation portion should also be updated to suggest installing the tagged v0.1.0, instead of directly installing from main

#

While it's a bit above-and-beyond, it may be useful to write down the intended release process as well. The linter has this so that other maintainers can take the reins in case I ever stop working on the project

#

Feature-wise, I'm super happy with what we have so far. There's been lots of praise over in #1271949921708146770, and a few good bug reports too! Ignoring the docs bits, I think the CLI is ready for release

#

Which is actually awesome! super_bevy super_bevy

pale viper
limber wedge
pale viper
limber wedge
pale viper
#

If everything goes well, we may end up release Bevy 0.16, bevy_cli v0.1.0, and bevy_lint v0.3.0 at the same time!

pale viper
limber wedge
#

and fix the conflicts then

pale viper
#

Totally!

sturdy tapir
#

As mentioned here

#editor-dev message

Any info on CLI having templates added by user?

limber wedge
sturdy tapir
twilit dew
#

When providing a GitHub URL, it will check that repo for a valid cargo-generate template

sturdy tapir
twilit dew
#

the -t foo shortcut just evaluates to https://github.com/TheBevyFlock/bevy_new_foo

#

With a special case for bevy_new_minimal, which is used when no -t param is passed

twilit dew
#

Pseudo syntax:
bevy template add source janhohenheim could add my GitHub to the places to look for templates

#

Then bevy new -t networking could first check https://github.com/janhohenheim/bevy_new_networking and then https://github.com/TheBevyFlock/bevy_new_networking

twilit dew
#

But yeah bottom line is that the CLI already today accepts arbitrary user-provided URLs for the templates 🙂

sturdy tapir
twilit dew
#

BTW @sturdy tapir I really appreciate that you're trying to not duplicate feature implementations across the launcher and the CLI heart_lime

#

Makes the work much easier for everyone involved 🙂

sturdy tapir
#

Or maybe the search bar...

finite crag
#

Right, so I see it all boils down to cargo-generate templates

sturdy tapir
#

Installing rust is pretty easy compared to search bar lol

finite crag
#

Which fit exactly what I imagined they would anyway.

limber wedge
finite crag
#

But that seems easy? I imagine cargo-generate has an appropriate API to access that.

near mist
#

bevy new does not support that yet afaik, but it's a thin wrapper over cargo generate so it should be possible

twilit dew
sturdy tapir
near mist
# 
$ bevy new -h
Create a new Bevy project from a specified template

Usage: bevy new [OPTIONS] <NAME>

Arguments:
  <NAME>  The desired name for the new project

Options:
  -t, --template <TEMPLATE>  The name of the template to use for generating the project [default: minimal]
  -b, --branch <BRANCH>      The git branch to use [default: main]
  -v, --verbose              
  -h, --help                 Print help (see more with '--help')
sturdy tapir
#

Can we have more options to fill out the cargo.toml?
Description/Authors/Rust Edition etc

near mist
twilit dew
sturdy tapir
finite crag
#

That's annoying

near mist
#

huh i think it does actually

# 
      --values-file <FILE>  Pass template values through a file. Values should be in the format `key=value`, one per line
#

if this does what it sounds like

#

oh you can pass it directly in the command actually

#

with --define <key>=<value>

#

you would have to know the names of the keys that the template supports, but that can be standardized for bevy templates for common things like author etc

#

(source: cargo generate -h)

finite crag
#

cargo-generate has some interesting doc comments lol

image.png
twilit dew
#

not sure if that's the same thing though

finite crag
#

Does bevy_cli use cargo generate as a binary or as a library?

near mist
slim pine
#

I saw that the lint for unconventional naming was merged, and it enforces a FooSet naming convention. When this was originally discussed though (starting here), this was somewhat contentious; at the start, people were maybe generally more in favor of FooSet, but at the end it seemed like consensus was largely on FooSystems instead, with Cart being biased towards that and Alice (and me) also preferring that over FooSet in the end

near mist
slim pine
twilit dew
limber wedge
finite crag
# near mist as a library

I suppose it should then be reasonably easy to extract the info on which parameters need to be defined from cargo-generate (though I can't say I've found the relevant methods in the docs)

twilit dew
#

Well, not manually manually, but parsing the TOML

#

you know what I mean 😄

finite crag
#

Yeah, I was just hoping we'd re-use the mechanism that already has to exist in cargo-generate anyway, but you're right.

twilit dew
#

As a heads-up @sturdy tapir, the 2d template has a post-generate hook that generates a prompt in the terminal, asking whether the user wants to execute the cargo update line at the bottom.

#

Dunno if there's a way to auto-confirm that prompt 🤷‍♂️

slim pine
#

as you can see, Bevy's system set naming is rather inconsistent 😂

image.png
twilit dew
near mist
#

that's for cargo generate again, not bevy new

twilit dew
limber wedge
slim pine
#

the PR description might take a while 😂

limber wedge
pale viper
limber wedge
#

btw is it possible to use the machine applicable fixes already? cargo check does not provide that (since its done using cargo fix iirc) so i assume bevy_lint does neither? @pale viper

pale viper
#

After looking at it, I guess it isn't! Clippy provides cargo clippy --fix, so it may be good to copy them

#

I bet it's possible to call RUSTC_WORKSPACE_WRAPPER=bevy_lint_driver cargo fix to get the same result

sturdy tapir
pale viper
#

@sturdy tapir when you say the editor uses the CLI, does it use it as a library or does it install and run the program?

limber wedge
pale viper
#

We originally designed bevy_cli to be friendly as a library, although I don't know if that still applies

sturdy tapir
pale viper
#

Good to know! Hopefully the upcoming release will provide a bit of API stability for you folks

sturdy tapir
#

I need to figure out text input first but once I do imma work on the create project stuff.

pale viper
limber wedge
sturdy tapir
#

#editor-dev message

pale viper
#

Ooooo, there's a lot of work being done in different branches and forks. I see!

sturdy tapir
#

Launcher is the only fully unblocked item imo

pale viper
#

That's super exciting! Let us know if you need any help integrating the CLI, it seems like a good idea to join the CLI and linter efforts under the editor wing :)

#

Especially since we can't be a working group forever

sturdy tapir
pale viper
#

Fair enough, but the CLI cannot remain a working group forever, as those need a specific end goal. The goal of the CLI and linter are to become official tools, and once that happens, this working group will likely be closed

#

My thoughts were to migrate communication over to #editor-dev, since the work is similar. It may need to be renamed, though (maybe tooling-dev?)

#

But that's far enough in the future that we don't have to worry about it yet :)

sturdy tapir
pale viper
#

Lol

sturdy tapir
#

got discord integration

sturdy tapir
# sturdy tapir

I might make this a 3rd party crate cause discord integration seems really useful

near mist
pale viper
#

@foggy basin I know Github Actions are usually your cup of tea, but if anyone wants to try their hand at it feel free!

near mist
#

Slightly off topic, but would anyone like to review a small PR that aims to make buttons more ergonomic to spawn in bevy_new_2d? The main question is whether the SpawnObserver boilerplate in widget.rs is a reasonable price to pay, keeping in mind users of all levels of experience with bevy may use the template

molten merlin
near mist
molten merlin
#

and since you already have to understand the Spawn apis to understand what button/SpawnObserver, etc is doing, its reasonable to "just use the existing APIs" rather than build a new observer spawning abstraction

#

(lmk if I misunderstood something about the example or whatnot)

near mist
#

Ah I'll have to try that, I wasn't aware of SpawnWith

#

It looks like what I would've wanted if I knew about it

limber wedge
foggy basin
lusty galleon
#

My app needs to be plopped into an existing html canvas, so hiding the loading screen when a canvas is added isn't working for me -- how are folks detecting that bevy has been initialized?

#

I ended up moving the mutation observer to my canvas and removing the loading screen when bevy modifies its height, which seems to work well enough.

foggy basin
#

Making it easier to customize the web assets to fit into other contexts is high on the list of things I want to improve

twilit dew
pale viper
#

bevy_new_2d is still being built with the web profile, the CLI just noticed that wasm-bindgen wasn't installed so it did so for you :)

twilit dew
#

oooh okay 🙂

#

thanks for clarifying!

#

Doing bevy test web in a CI run would be really cool

pale viper
#

Ooohh, good idea!

pale viper
#

<@&1064695155975803020> bevy_lint is ready for its v0.3.0 release! Just like the last two releases, we need at least one maintainer approval on https://github.com/TheBevyFlock/bevy_cli/pull/392 before it becomes official. Now's your chance to try it out, browse the documentation and changelog, and request any changes that you may want!

#

The PR description has more information on how to test bevy_lint, and it links to the release process document as well in case you need a refresh

#

Let me know if you have any questions! :)

rocky oxide
pale viper
twilit dew
limber wedge
twilit dew
#

hmm, that didn't work

#

did I mistype something?

#

oh wait it's rustflags not rust_flags 😄

#

I think it's building happily along now 🙂

limber wedge
#

Hahaha

twilit dew
limber wedge
#

For me it was always the case when you used rand

twilit dew
#

Eh, as long as it builds, I'm happy

limber wedge
#

Yea not sure maybe its because we use the wasm-unknown-unknown target and that does not have built in seeding or something like this

#

And perhaps trunk or w.e used a different target or had something else configured

buoyant jasper
#

BTW moving away from trunk to bevy cli made things incredibly simpler for my use case 😅

twilit dew
buoyant jasper
twilit dew
pale viper
pale viper
limber wedge
pale viper
twilit dew
#

little question: if I write this:

[package.metadata.bevy_cli.web.release]
default_features = false

are the cargo defaults for release still used on top of that?

limber wedge
twilit dew
pale viper
#

Actually, I believe you can use bevy web build --verbose to log the final configuration

twilit dew
# 
DEBUG Using defaults from bevy_cli config:
      features = []
      default_features = false
      rustflags = ["--cfg", 'getrandom_backend="wasm_js"']
 INFO Compiling to WebAssembly...
DEBUG Running: `cargo build --config profile.web.inherits="dev" --config profile.web-release.inherits="release" --config profile.web-release.opt-level="s" --config profile.web-release.strip="debuginfo" --bin foxtrot --no-default-features --profile web-release --target wasm32-unknown-unknown`
#

That points to yes 🙂

#

thx!

limber wedge
#

Yes

rocky oxide
#

FYI I'm going to want a dedicated blurb for the Jam description about how to get started with the CLI, and what features might be most useful

limber wedge
near mist
# 
[package.metadata.bevy_cli.dev]
features = ["native_dev"]

[package.metadata.bevy_cli.web.dev]
features = ["web_dev"]

this doesn't work because then web.dev has both web_dev and native_dev features enabled

#

is there a way to do this?

#

ah i see there's a native.dev, nice

#

another question.. currently i'm setting [profile.dev] opt-level = 1 and [profile.dev.package."*"] opt-level = 3

#

i noticed bevy run web uses --profile web, which is distinct from --profile dev, where i've set those options

#

i assume that means those options won't get picked up for web dev builds?

#

and i assume there isn't a particular reason i wouldn't want those options enabled for web builds too?

#

or does profile web inherit from profile dev

#

ok major rubberduck, the answer is yes, it does, as mentioned right above in this thread :p

limber wedge
#

Just shows that we need to clean up the readme to include the new features. Will start if i have time today

near mist
#

could bevy CLI get like a man page for this type of info that doesn't fit in --help?

#

idk if windows has something similar

limber wedge
near mist
#

actually i think an mdbook style documentation might be even better (easier to read / navigate)

#

not that it's mutually exclusive

limber wedge
#

Yea i like mdbook more but maybe if you could create an issue for this so we dont forget it. Otherwise i can create one in the evening.

near mist
limber wedge
#

And then maybe alice has a preference

near mist
#

found a bug?

# 
# These bevy commands:
bevy build --release
bevy build --profile release

# Become these cargo commands:
cargo build --features native --profile release
cargo build --features native,native_dev --profile release
#

i would have expected them to be treated the same

#

in release workflow i use --profile=${{ matrix.profile }} to be generic instead of the --release shorthand

#

although i guess i can switch to --release in practice

limber wedge
#

Not a bug but maybe not the intended behavior? You would like that the cli checks if the release profile is used and if so merge the release configs and not the dev once?

near mist
#

so yeah i think it should special-case when the profile is named release

#

and same thing for --profile web-release, that should be treated as web.release, not native.dev

#

it seems like any custom profile uses the native.dev settings atm

limber wedge
#

To assume if you pass the specific profiles to also use the same merging method as if the cli argument for web/ release was passed what do you think @foggy basin

foggy basin
foggy basin
#

In any case, I'm open to change this logic :)

limber wedge
foggy basin
#

@pale viper @limber wedge I will attend RustWeek and the Bevy unconf in 2 weeks and plan to talk about and gather feedback for the Bevy CLI there.
Is there anything specific you'd like me to find out or should present?

pale viper
#

I would also appreciate if you could get a grasp of how large our user-base is. I don't have a clue how many people are using the CLI and linter, but would like to know that!

#

If we get enough popularity, that should help us become official

foggy basin
pale viper
#

No, but it's better than nothing at all :D

#

Or the graph of how many clones we get a day:

foggy basin
#

Interesting, what's bevyskein.dev?

pale viper
#

That's @molten merlin's Blender integration for Bevy

#

He can probably talk better on it than I can, but the docs look great :)

foggy basin
#

Ahhh I saw some social media posts about that, looked very useful :)

pale viper
#

Github, Google, and DuckDuckGo make sense, but it's interesting that we're linked to from the Rust forums