Is there a way to run cargo udeps on NixOS on a project that uses the stable toolchain?

No idea, not familiar with udeps

And should I use rustup or not use rustup?

I would recommend against it and instead recommend either fenix or rust-overlay

I've been developing with a direnv+flake that does pkgs.rustPlatform.buildRustPackage and for devShells takes inputsFrom that derivation. And setting RUST_SRC_PATH

This all sounds fine

and removing any $HOME/.cargo/bin entries from PATH in my shellHook—not sure if the latter is right or not, and I also don't 100% remember why I've done it, but I would assume any dynamically linked binaries there to rot when the store gets GCd.

Yeah you'll hit issues compiling/running stuff that gets installed there. Instead of doing shellHook crimes you should simply never have anything in this directory in the first place. For example, never use cargo install, always package it with nix (if no existing package is available) and install it that way

For cargo udeps, I'm told I should use cargo +nightly udeps, which tells me to use rustup

Yeah, the +toolchain syntax is a rustup thing, only works on rustup shim binaries for cargo and such, not the actual regular binaries. You can use fenix or rust-overlay to get a nightly toolchain, if you want to use stable most of the time you could have two devshells, one for stable and one for nightly

I noticed there's also a cargo-udeps packaged in nixpkgs (how if it requires nightly??)

It probably doesn't require nightly to build, just to run, but that's a guess. Also I think there are some things in nixpkgs that do actually need nightly to build, so that's not too crazy

but nix-shell -p cargo-udeps --command "cargo udeps" outputs the same errors.

Likely because it uses the toolchain from your ambient environment (which in this case is a stable toolchain) rather than e.g. being wrapped to force a particular toolchain (which would be awful UX-wise, so that's why it's not done that way)

cargo-nextest is broken on aarch64-darwin:

error: custom attribute panicked
  --> nextest-runner/src/usdt.rs:63:1
   |
63 | #[usdt::provider(provider = "nextest")]
   | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
   |
   = help: message: called `Result::unwrap()` on an `Err` value: IO(Os { code: 2, kind: NotFound, message: "No such file or directory" })

error[E0433]: failed to resolve: could not find `usdt_probes` in `usdt`
   --> nextest-runner/src/usdt.rs:205:23
    |
205 |           $crate::usdt::usdt_probes::run__done!(|| {
    |                         ^^^^^^^^^^^ could not find `usdt_probes` in `usdt`
    |
   ::: nextest-runner/src/runner/imp.rs:381:9
    |
381 | /         crate::fire_usdt!(UsdtRunDone {
382 | |             run_id: self.run_id,
383 | |             profile_name: self.profile.name().to_owned(),
384 | |             total_tests: run_stats.initial_run_count,
...   |
389 | |             paused_nanos: _stopwatch_end.paused.as_nanos() as u64,
390 | |         });
    | |__________- in this macro invocation
    |
    = note: this error originates in the macro `crate::fire_usdt` (in Nightly builds, run with -Z macro-backtrace for more info)

In reply to @quadradical:federated.nexus
i reccomens using crane combined with fenix, i found it great myself. perhaps fenix alone is enough for you though.