Can't run cargo-flowistry on NixOS

[sledgehammervampire]

I installed flowistry via the vscode extension. After patching the rpath of the cargo-flowistry and flowistry-driver binaries, I still get this error when running a flowistry command in vscode:

Flowistry could not run because your project failed to build with error:
error: could not execute process `/home/rdp/.cargo/bin/cargo-flowistry flowistry effects /home/rdp/src/downloader/src/lib.rs 2453` (never executed)

Caused by:
  No such file or directory (os error 2)

Invoking cargo flowistry gives:

$ cargo flowistry
error: could not execute process `/home/rdp/.cargo/bin/cargo-flowistry flowistry` (never executed)

Caused by:
  No such file or directory (os error 2)

Invoking the cargo-flowistry binary directly gives:

$ cargo-flowistry
bash: /home/rdp/.cargo/bin/cargo-flowistry: No such file or directory

Both cargo-flowistry and flowistry-driver exist:

$ which cargo-flowistry
/home/rdp/.cargo/bin/cargo-flowistry

$ which flowistry-driver
/home/rdp/.cargo/bin/flowistry-driver

The usual suspect for these errors on NixOS is a missing dynamic library. But I have patched the binaries so that the libraries are found:

$ ldd /home/rdp/.cargo/bin/cargo-flowistry
        linux-vdso.so.1 (0x00007ffc02f14000)
	libLLVM-13-rust-1.57.0-nightly.so => /home/rdp/.rustup/toolchains/nightly-2021-10-08-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/libLLVM-13-rust-1.57.0-nightly.so (0x00007f0cee73e000)
	libgcc_s.so.1 => /nix/store/mij848h2x5wiqkwhg027byvmf9x3gx7y-glibc-2.33-50/lib/libgcc_s.so.1 (0x00007f0cee724000)
	libpthread.so.0 => /nix/store/mij848h2x5wiqkwhg027byvmf9x3gx7y-glibc-2.33-50/lib/libpthread.so.0 (0x00007f0cee704000)
	libm.so.6 => /nix/store/mij848h2x5wiqkwhg027byvmf9x3gx7y-glibc-2.33-50/lib/libm.so.6 (0x00007f0cee5c3000)
	libdl.so.2 => /nix/store/mij848h2x5wiqkwhg027byvmf9x3gx7y-glibc-2.33-50/lib/libdl.so.2 (0x00007f0cee5be000)

$ ldd /home/rdp/.cargo/bin/flowistry-driver
        linux-vdso.so.1 (0x00007ffd395d9000)
	librustc_driver-2cdae8a62fc3a991.so => /home/rdp/.rustup/toolchains/nightly-2021-10-08-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/librustc_driver-2cdae8a62fc3a991.so (0x00007f14c1dfa000)
	libstd-8adcca4f1427867b.so => /home/rdp/.rustup/toolchains/nightly-2021-10-08-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/libstd-8adcca4f1427867b.so (0x00007f14c1a4e000)
	libgcc_s.so.1 => /nix/store/mij848h2x5wiqkwhg027byvmf9x3gx7y-glibc-2.33-50/lib/libgcc_s.so.1 (0x00007f14c1a34000)
	libpthread.so.0 => /nix/store/mij848h2x5wiqkwhg027byvmf9x3gx7y-glibc-2.33-50/lib/libpthread.so.0 (0x00007f14c1a14000)
	libc.so.6 => /nix/store/mij848h2x5wiqkwhg027byvmf9x3gx7y-glibc-2.33-50/lib/libc.so.6 (0x00007f14c184f000)

[mainrs]

Is it marked as executable? E.g. chmod +x ...?

[Freax13]

You also need to fix the interpreter path.

[beeb]

I created a derivation that builds flowistry_ide from source here: https://github.com/beeb/.dotfiles/blob/main/pkgs/flowistry/default.nix

The binary seems to work fine and I can run cargo flowistry which shows no output (but no errors).

cargo-flowistry and flowistry-driver are available on the path.

However, the extension still seems to want to have rustup to work, but I do not have rustup on my system. What do I need to do to use the extension if I don't want rustup? I manage my rust toolchain with nix and can't use rustup at the same time.

I'm on Ubuntu btw, not nixOS, but I suspect the problem is not relevant to the OS.

[willcrichton]

The issue is that Flowistry needs to download a specific nightly toolchain of the Rust compiler for it to work. Flowistry would need some kind of abstraction over toolchain managers that would support Rustup, Nix, and the like. I don't have the time to implement that, but I would accept such a contribution.

[beeb]

@willcrichton thanks for the reply. You mean that the nightly toolchain is required at runtime, correct? So it's unable to run even if it was compiled with all required dependencies?

[willcrichton]

That's right, the nightly toolchain is required at runtime because compiler plugins are dynamically linked against the compiler.