The maintainers are keen on supporting hot reloading in Bevy itself, and at least personally, I would prefer to colalborate with the rest of the ecosystem.

Before adopting this fully, I'd like more investigation / docs into exactly how this would be used by Bevy devs, and the constraints and risks imposed. We don't have a ton of bandwidth to investigate this fully (nor do I personally have the requisite expertise on the technical / implementation side), so I would really value a cohesive design doc or other write-up.

Here's a little something I threw together to use in the meantime :)
https://github.com/janhohenheim/bevy_simple_subsecond_system

We're exploring this as a working group: https://discord.com/channels/691052431525675048/1374187654425481266/1374187654425481266

Design doc can be found at: https://hackmd.io/@bevy/SkdMQIYWle/edit

Joint prototype: https://github.com/TheBevyFlock/bevy_simple_subsecond_system/

I am interested in integrating subsecond into iced as well.

I feel that the part of the puzzle that is missing is a standalone version of dx serve --hot-patch (i.e. a server implementing the subsecond protocol). Ideally, it'd be a cargo subcommand (e.g. cargo hot) acting as a drop-in replacement of cargo run.

This way, the whole ecosytem can benefit without specifically depending on the Dioxus build process.

I'm not sure if there are any efforts in this direction, but I will look into isolating the relevant parts of dioxus-cli soon myself.

I feel that the part of the puzzle that is missing is a standalone version of dx serve --hot-patch (i.e. a server implementing the subsecond protocol). Ideally, it'd be a cargo subcommand (e.g. cargo hot) acting as a drop-in replacement of cargo run.

This is something that Bevy is interested in too :)

Cool!

I am working on it over here: https://github.com/hecrj/cargo-hot

I've got the Fat linking stage working. Now I'm getting to the fun part. Will keep you posted.

Cool!

I am working on it over here: https://github.com/hecrj/cargo-hot

I've got the Fat linking stage working. Now I'm getting to the fun part. Will keep you posted.

I get that dioxus is open source, but we've been working on this for the better part of the last year and seeing our work immediately ripped out like this is upsetting.

The least you could do is help us spin dx out into a general tool for anyone in the ecosystem, not just clone our work wholesale and package it into another tool.

There are bugs and dragons abound and big work ahead like proper workspace support. Lots of sweat and long nights went into this, hand-rolled assembly, and head banging to figure out esoteric hacks to get it working. I would love it if the community came together to help maintain a "cargo plus plus", not just extricate our work to put their own name on it.

It's understandable if some random fly-by contributor did this, but the head of another large rust project doing it without even reaching out is disappointing.

"cargo plus plus"

That's how you kill an ecosystem. It should be a cargo subcommand, please.

"cargo plus plus"

That's how you kill an ecosystem. It should be a cargo subcommand, please.

wasm-bindgen, wasm-pack, and trunk are not cargo subcommands. cargo cannot run, test, or bench wasm, ios, android projects nor does it properly assemble app bundles. wasm-bindgen is the most used cli in the rust ecosystem and it is not a subcommand.

@jkelleyrtp what is it that you actually want?

I understand Dioxus/you put a lot of work into creating subsecond and hot patching and should be referenced etc. (did an amazing job :) )
but currently at least subsecond and the cli required is very closely tied to Dioxus(i.e. source control, release cycle etc).
IMO this is not the best for the rust ecosystem as whole as its makes harder to patch and change as required for the whole ecosystem of crates and also means that the Dioxus-cli is required to use hot reloading which is small subset of the total functionally.

to solve some of these issues it makes sense to me to have a separate source control etc for the pure functionally of hot reloading.
i actually think it might make sense to create an entire github org to handle subsecond and required crates (since it seems to be makeing waves in the rust ecosystem).

i think it would be useful to answer what you were wanting/expecting.
were you wanting all related subsecond to remain under Dioxus and to what extent.
would you be willing to move the subsecond and other required functionality to a separate source control (in or out of DioxusLabs org).

not just extricate our work to put their own name on it.

i dont think anyone wanted to take your work and put their name on it.
in the case of https://github.com/hecrj/cargo-hot/tree/master
its currently very experimental its has 4 commits and doesnt even have a readme.
it currently references your name in the license(did you want somthing else?) and was created for trying out functionally without the full Dioxus cli

wasm-bindgen, wasm-pack, and trunk are not cargo subcommands. cargo cannot run, test, or bench wasm, ios, android projects nor does it properly assemble app bundles. wasm-bindgen is the most used cli in the rust ecosystem and it is not a subcommand.

@jkelleyrtp I'd argue it still makes sense as a subcommand, even though others aren't. Cargo subcommands are basically the same as git subcommands - they just attach a prefix, and your binary works the same as standalone. The only difference (from a rudimentary check of making one) is that they automatically set some environment variables in addition, specifically:

• CARGO_HOME - $HOME/.cargo usually
• RUSTUP_TOOLCHAIN - current target triple
• SSL_CERT_DIR - in my case, /etc/ssl/certs
• SSL_CERT_FILE - in my case, /etc/ssl/cert.pem
• RUST_RECURSION_COUNT - just a general recursion counter
• RUSTUP_HOME - $HOME/.rustup usually
• LD_LIBRARY_PATH - it injects the current rust toolchain lib dir
• CARGO - Full path to the cargo binary for the current active toolchain

as well as adding the actual cargo subcommand name as the first argument.

In the case of the standard dx CLI, it makes sense to be standalone - dioxus is not just a rust tool, and can be initialized via npm too. So requiring it be a cargo subcommand may be a little constraining.
On the flipside, the cargo subcommands do work without cargo, as they are just named as cargo-binname so you can run it as that. For a rust ecosystem tool, I think it makes more sense for it to be a cargo subcommand, if we are trying to make it widely reusable as the dioxus project seems to hope for. The dx cli can just inject what it needs into the argument list when running as a subcommand, assuming that's how you guys would integrate it if it were to be split out.

Many cargo-installed binaries I use don't work as a cargo subcommand, but generally the differentiator between ones that do and ones that don't are if they are specifically about rust code and operating on your actual codebase (with the exception of cargo-install-update, which is a cargo subcommand but doesn't operate on a codebase level - still makes sense to me).
I'd argue that a subsecond CLI tool makes a lot of sense as a cargo subcommand, given the general pattern I've seen.

@jkelleyrtp I am very grateful for all your amazing work; but I don't think you get what open source means.

Even then, I don't think an exploration that is ~8 hours old warrants this reaction. I enjoy exploring on my own and I had no ill intent. In fact, I thought Dioxus could eventually switch to it and join efforts.

I am sorry to disappoint, but I don't need to "reach out" when I am already working right here in the open.

In any case, I am happy to cooperate and join efforts with anyone that would find this tool useful. I am definitely not the right person to maintain it!

Re: cargo subcommand vs own command

The frustrations with cargo's limitations and its glacial development cycle has led this very project to design the Bevy CLI alpha as a cargo replacement / wrapper and not a subcommand.

I think it's worth not immediately dismissing the validity of a cargo v2. As Jon points out, quite a few projects have come to the conclusion that cargo is often simply not enough. The discussion of whether we want to collectively encourage the ecosystem to migrate to a cargo replacement or not is certainly out of scope for this wee issue. For prolonged discussion of this, I suggest moving to a dedicated issue on the Dioxus repo instead.

For Bevy's use-case, the relevant PR is not even merged yet, the feature is experimental, and the Dioxus version it depends on is in alpha. Really, we should be fine with some hoops right now IMO.

The frustrations with cargo's limitations and its glacial development cycle has led this very project to design the Bevy CLI alpha as a cargo replacement / wrapper and not a subcommand.

@janhohenheim I am kinda curious - what were the limitations found? Do you have a link to a discussion on the discord or here on github about this? I'm unaware of such limitations as I don't tend to work on CLI tools much, so I'm very interested where the limitations have been found.

@BD103 @TimJentzsch ^

(Offtopic) Bevy CLI:

• bevy cli #436
• https://hackmd.io/cCHAfbtaSviU_MDnbNHKxg
• https://github.com/TheBevyFlock/bevy_cli