Dependency uses nightly toolchain even when building app with stable toolchain

[alerque]

Singe the topic came up in #4227 of an immanent stable release, I had another look at the Arch Linux packaging (currently the Git HEAD based VCS package in the AUR, but with an eye to making an official stable package when the time comes). I tried building it with a stable Rust toolchain but it fails:

error: failed to run custom build command for `raster-nodes-shaders v0.1.0 (/build/graphite-editor-git/src/graphite-editor-git/node-graph/nodes/raster/shaders)`

Caused by:
  process didn't exit successfully: `/build/graphite-editor-git/src/graphite-editor-git/target/release/build/raster-nodes-shaders-0590a2ab379ae769/build-script-build` (exit status: 1)
  --- stdout
  cargo:rerun-if-env-changed=RASTER_NODES_SHADER_PATH
  cargo:rerun-if-env-changed=RUST_GPU_PATH_OVERRIDE
  cargo:rerun-if-env-changed=RUSTC_CODEGEN_SPIRV_PATH

  --- stderr
  [2026-06-12T09:33:05Z INFO  cargo_gpu_install::install] cache directory is '/build/.cache/rust-gpu'
  [2026-06-12T09:33:05Z DEBUG cargo_gpu_install::spirv_source] Running `cargo metadata` on `/build/graphite-editor-git/src/graphite-editor-git/node-graph/nodes/raster/shaders/entrypoint`
  [2026-06-12T09:33:05Z DEBUG cargo_gpu_install::spirv_source] Parsed `rust-gpu` source and version: CratesIO(Version { major: 0, minor: 10, patch: 0, pre: Prerelease("alpha.1") })
  [2026-06-12T09:33:05Z DEBUG cargo_gpu_install::spirv_source] Parsed `SpirvSource` from crate `/build/graphite-editor-git/src/graphite-editor-git/node-graph/nodes/raster/shaders/entrypoint`: CratesIO(Version { major: 0, minor: 10, patch: 0, pre: Prerelease("alpha.1") })
  [2026-06-12T09:33:05Z DEBUG cargo_gpu_install::install] writing `rustc_codegen_spirv_dummy` source files into '/build/.cache/rust-gpu/codegen/0_10_0-alpha_1'
  [2026-06-12T09:33:05Z DEBUG cargo_gpu_install::install] resolving toolchain version to use
  [2026-06-12T09:33:05Z DEBUG cargo_gpu_install::spirv_source] Running `cargo metadata` on `/build/.cache/rust-gpu/codegen/0_10_0-alpha_1`
  [2026-06-12T09:33:09Z DEBUG cargo_gpu_install::spirv_source] Parsing `build.rs` at "/build/.cargo/registry/src/index.crates.io-1949cf8c6b5b557f/rustc_codegen_spirv-0.10.0-alpha.1/build.rs" for the used toolchain
  [2026-06-12T09:33:09Z INFO  cargo_gpu_install::install] selected toolchain channel `"nightly-2026-04-11"`
  [2026-06-12T09:33:09Z DEBUG cargo_gpu_install::install] ensure_toolchain_and_components_exist
  Error: ensuring toolchain and components exist

  Caused by:
      0: Failed to launch cmd `rustup toolchain list -q`
      1: No such file or directory (os error 2)

I would suggest this needs to get addressed before release so the whole thing can be built with a single stable toolchain, not some pinned nightly if possible. If not possible this needs to be better documented. In that event I would also suggest setting the main project toolchain defaults to match this deep dependency so that the build requirements were clear upfront and the whole thing is built with the same toolchain instead of mixing and matching.

[TrueDoctor]

I was about to add a comment on the aur package, but we might as well discuss that here

[TrueDoctor]

We would in general recommend using the shaders we build in our ci to buid graphite. The nightly toolchain is only used for compiling the shaders. Using the prebuilt ones should make the build process a lot simpler and reduce compilation times. This is also what we do for packaging for nix os. Then everything should just work with a stable toolchain

[timon-schelling]

Currently shaders are pushed here for every commit on master https://github.com/timon-schelling/graphite-artifacts

[alerque]

For Arch Linux packages we're not particularly interested in reducing compilation times or even in simplifying the process. Not that those are bad things, they are just secondary concerns to reproducibility and transparency. Using binary blobs we download from somewhere/anywhere is very much less than ideal for those goals, especially when it is possible to build from sources. We don't like just shipping binary blobs even when they are upstream built/official/signed blobs.

End users will not be affected by the build time or complexity, those are only things that packagers have to deal with. They should care about whether the prebuilt packages they get can pass rebuilderd checks and what level of supply chain security / transparency there is.

[0HyperCube]

the whole thing can be built with a single stable toolchain

The rust-gpu project is a custom backend using internal rustc APIs. This means (from my understanding) it will never run on stable and so has a pinned nightly version for each release.

setting the main project toolchain defaults to match this deep dependency

Using an unstable toolchain for the whole project would apply crates that do not need the GPU shaders. These crates may be used outside of the editor GUI.

reproducibility

Since the artifacts are on a GitHub commit, I think that there can be reasonable confidence in its persistence.

We don't like just shipping binary blobs

It is text based wgsl but without preserving identifier names. I guess you can choose between using that and using the unstable rust toolchain.

[timon-schelling]

We don't like just shipping binary blobs

It is text based wgsl but without preserving identifier names. I guess you can choose between using that and using the unstable rust toolchain.

*Using two toolchains (stable and the pinned nightly).

sorry we can't really do anything about that. Using a stable toolchain for the application and the pinned nightly in the very limited shader case is the only sane way we see.

[Torxed]

I'll add to what @alerque said so we'll, that we also strongly prefer if builds are reproducible. I'm not familiar with Rust enough to say if this is by default or not. But in case Rust isn't, this is also worth keeping in mind if possible.

[alerque]

Given the situation with the shader as explained I think the best approach would be to provide build instructions for the shader as an independent build step and amend the build process for the main crates such that it is clear how to inject a previously built shader artifact ourselves. That way we can build everything ourselves and provide some transparency on what is going on and achieve reproducible builds.

One of the main bothersome factors now is that building the parent project from source automatically does something behind the scenes that launches a separate build using a different toolchain and even tries to fetch and install that toolchain automatically. That's a pretty big no-no in the middle of a build. We need to download all the sources first, do any prep work we need to, then in a separate phase build everything. The build phase should work without internet access.

Using a specific pinned nightly toolchain isn't ideal but it isn't going to be a blocker. The build process automatically trying to use rustup to fetch it's own toolchain in the middle of a build that was started on a different toolchain provided ahead of time is not kosher.

[0HyperCube]

Seems totally reasonable @alerque.

You can build the shaders using:

cargo check -p raster-nodes-shaders

This runs the build.rs which automatically downloads the relevant nightly rust version and builds the codegen-spirv (from rust-gpu). If you want to download your own rust-gpu and to build the spirv generator create yourself, use the RUSTC_CODEGEN_SPIRV_PATH and RUST_GPU_PATH_OVERRIDE environment variables respectively.

The output is in target/spirv-builder/spirv-unknown-naga-wgsl/release/deps/raster_nodes_shaders_entrypoint.wgsl.

You can inject the pre-built shaders by setting the RASTER_NODES_SHADER_PATH environment variable to the absolute path to the wgsl file.