Added a shell.nix for easy development using Nix

[RLangendam]

Objective

Support using nix-shell for Nix-based environments.

Solution

Add a shell.nix with the required dependencies for bevy. This only assumes a working Rust-development environment to be already present.

Testing

• cargo build --all
• cargo test --all

---

Showcase

$ nix-shell
$ cargo build --all

[github-actions]

Welcome, new contributor!

Please make sure you've read our contributing guide, as well as our policy regarding AI usage, and we look forward to reviewing your pull request shortly ✨

[mockersf]

A new file at repository root needs to be useful for everyone. Can it live elsewhere?

[RLangendam]

No, it needs to be at the root. This way the environment can be automatically activated when you open the repo or when you navigate to it.

The alternative would be to keep the file local, but this is annoying. I think it does belong in the repo as it properly configures the build environment.

Alternatively, we could change it to a flake.nix with .envrc for further improving reproducible builds by having control over the Rust toolchain as well. Just let me know what you think is better.

[RLangendam]

I was thinking about your remark: "useful for everyone". I think it would be an improvement if developers start using flakes more to have reproducible builds locally. This saves a lot of the hassle from "it works on my machine". See also, https://lab.abilian.com/Tech/Linux/Packaging/Nix/Nix%20Flakes%20-%20Why%3F/

[mockersf]

No, it needs to be at the root. This way the environment can be automatically activated when you open the repo or when you navigate to it.

Then I would be against including this in the repo. We don't want to have people local tooling reflected here.

[RLangendam]

This is an interesting position to take. After all, the things mentioned in shell.nix are build dependencies, not local tools. The requirement of having these dependencies is not mentioned anywhere in the bevy dev docs. You have to find out by seeing your local build fail and install more stuff.

In the same way the dependency on the Rust toolchain (versions, stable/nightly, graphics backend, and so on) is not pinned down, leading to many untested variations in the field.

I think it would be very beneficial to have these things pinned down, mentioned in the repo and create an ergonomic developer experience. In the future, running all tests in different version locked environments will improve quality. Simply being against files at the root seems like a very weak argument against this.

[RLangendam]

I think we should consider using flakes anyway, since we already document them. See also, #24301 (comment)