Add a nix devShell for webapp development

[j4ger]

In addition to the existing nix devShell config, which is for developing dioxus itself, this pull request adds a web devShell for developing web applications with dioxus.

Although dioxus-cli is available in nixpkgs, it does not update with main branch and it doesn't integrate well with versioned rust environment (due to the missing or non-functioning rustup). The new devShell config builds dx based on the repo and inserts a mock-up rustup to bypass dx's toolchain verification process, allowing it to automatically install the corresponding versioned wasm-bindgen (I couldn't come up with a better way to make it use a wasm-bindgen provided by the flake, other than wrapping dx with modified $XDG_STATE_HOME, which would also interfere with other parts of the program using related envvars).

Fixes #3083 (sort of?)

[crabdancing]

Is there no option for dioxus-cli to be changed so you can override tool behavior directly with a CLI flag? Relying on compilation solution where dx fetches its own tools isn't a very good way of handling reproducibility, IMO, and would also break Nix pure build of Dioxus apps.

It would work as a temporary stopgap to allow impure dev env to work, but why not just PR to add a dedicated environment variable or CLI flag for controlling this? Has DioxusLabs already rejected such a solution?

[j4ger]

Is there no option for dioxus-cli to be changed so you can override tool behavior directly with a CLI flag? Relying on compilation solution where dx fetches its own tools isn't a very good way of handling reproducibility, IMO, and would also break Nix pure build of Dioxus apps.

It would work as a temporary stopgap to allow impure dev env to work, but why not just PR to add a dedicated environment variable or CLI flag for controlling this? Has DioxusLabs already rejected such a solution?

I agree that the current behavior of dx does not comply with the strict "nix philosophy", as it fetches its own build artifacts which is not isolated, but at least its version is fixed (mostly, since it uses the version number as the identifier, not hash).

The ideal solution would be some sort of envvars to specify wasm-bindgen path, but the exact behavior of the verification process needs to be changed.

Although, it just came to me that the proper behavior would be something similar to the rust toolchain itself: rustup has its own mechanism of determining whether it's part of a "managed" installation, if so, it would not attempt to modify the environment in any way, but simply provide diagnosis.

[crabdancing]

One problem I ran into is that your metadata is wrong.

nix run github:j4ger/dioxus#packages.x86_64-linux.dx
error: unable to execute '/nix/store/1drad9mli1zp3cqrqrxlqx3ydc2x5v3x-dioxus-cli-0.6.1/bin/dioxus-cli': No such file or directory

Because the package is named dioxus-cli, by default, it assumes the bin name is the same. Off the top of my head, I think what you want is meta.mainProgram = "dx"; in your build expression. I could be misremembering / not accounting for naersk-specific details.

I have a fair bit of experience in Nix, so I'd be willing to help develop the flake further if you want. Exposing the local dx utility in the package flake is definitely a step in the right direction.

[j4ger]

One problem I ran into is that your metadata is wrong.

nix run github:j4ger/dioxus#packages.x86_64-linux.dx
error: unable to execute '/nix/store/1drad9mli1zp3cqrqrxlqx3ydc2x5v3x-dioxus-cli-0.6.1/bin/dioxus-cli': No such file or directory

Because the package is named dioxus-cli, by default, it assumes the bin name is the same. Off the top of my head, I think what you want is meta.mainProgram = "dx"; in your build expression. I could be misremembering / not accounting for naersk-specific details.

I have a fair bit of experience in Nix, so I'd be willing to help develop the flake further if you want. Exposing the local dx utility in the package flake is definitely a step in the right direction.

Thanks for pointing it out. Originally I was fiddling around with the workspace build mechanism since there are multiple crates in the repo. According to naersk's document it should build the crate with the exact supplied name, but it didn't, so I had to use additional buildOptions.

Should be fixed now.