Relative paths are not part of a package's interface. We'll have to find a different solution.

You're absolutely right. I'll investigate alternative solutions

There doesn't seem to be a way to override it. This is what I've tried:

nix-repl> pkgs.rustPlatform.bindgenHook.override { clang = pkgs.clang_17; }
error:
       … while calling a functor (an attribute set with a '__functor' attribute)

         at «string»:1:1:

            1| pkgs.rustPlatform.bindgenHook.override { clang = pkgs.clang_17; }
             | ^

       … while calling a functor (an attribute set with a '__functor' attribute)

         at /home/dtc/documents/vcs/nixpkgs/lib/customisation.nix:104:43:

          103|       # Re-call the function but with different arguments
          104|       overrideArgs = mirrorArgs (newArgs: makeOverridable f (overrideWith newArgs));
             |                                           ^
          105|       # Change the result of the function call by applying g to it

       (stack trace truncated; use '--show-trace' to show the full trace)

       error: function 'anonymous lambda' called with unexpected argument 'clang'

       at /home/dtc/documents/vcs/nixpkgs/pkgs/build-support/rust/hooks/default.nix:92:32:

           91|
           92|     bindgenHook = callPackage ({}: makeSetupHook {
             |                                ^
           93|       name = "rust-bindgen-hook";

nix-repl> (pkgs.makeRustPlatform {rustc = pkgs.rustc; cargo = pkgs.cargo; clang = pkgs.clang_17;}).bindgenHook.clang
«derivation /nix/store/j16048gsic45ijdpw82172pfxdz9nw2w-clang-wrapper-16.0.6.drv»

For now, I'll setup a similar script just for this package that supports pinning the clang version, but this should be revisited at a later date to allow overriding this.

This looks like a bug. It can be fixed with this:

diff --git a/pkgs/development/compilers/rust/make-rust-platform.nix b/pkgs/development/compilers/rust/make-rust-platform.nix
index e22cb6d594af..6ed724aae821 100644
--- a/pkgs/development/compilers/rust/make-rust-platform.nix
+++ b/pkgs/development/compilers/rust/make-rust-platform.nix
@@ -1,4 +1,4 @@
-{ lib, buildPackages, callPackage, cargo-auditable, stdenv, runCommand }@prev:
+{ lib, buildPackages, callPackage, callPackages, cargo-auditable, stdenv, runCommand }@prev:
 
 { rustc
 , cargo
@@ -34,7 +34,7 @@ rec {
   };
 
   # Hooks
-  inherit (callPackage ../../../build-support/rust/hooks {
+  inherit (callPackages ../../../build-support/rust/hooks {
     inherit stdenv cargo rustc;
   }) cargoBuildHook cargoCheckHook cargoInstallHook cargoNextestHook cargoSetupHook maturinBuildHook bindgenHook;
 }

I'll investigate that later then, thanks :)
Should this be made in another PR, or does it make sense to include it in this one?

It makes sense to include here; it's a requirement for this to work. If you needed to refactor something else for this to work, you'd also put it here.

If this was to stall because of something related to pgvector directly, I'd advocate for spinning the refactors out into their own PRs but we'll cross that bridge when we get there.

Great, it seems to work fine in the repl. I've tested it by overriding clang to 17 and having it fail the build.
I'm just finishing building the package to make sure everything works fine, and then I'll push.
This will likely trigger a lot of package rebuilds in the CI, but we'll see 🙃

Relative paths are not part of a package's interface. We'll have to find a different solution.

Sorry, I didn't understand that comment, and I'm curious about this... Why is the relative path a problem? Also, for example, pkgs/os-specific/darwin/apple-sdk-11.0/default.nix does something similar:

    rustPlatform = pkgs.makeRustPlatform {
      inherit (pkgs.darwin.apple_sdk_11_0) stdenv;
      inherit (pkgs) rustc cargo;
    } // {
      inherit (pkgs.callPackage ../../../build-support/rust/hooks {
        inherit (pkgs.darwin.apple_sdk_11_0) stdenv;
        inherit (pkgs) cargo rustc;
        clang = mkCc pkgs.clang;
      }) bindgenHook;
    };

Relative paths are not guaranteed to remain stable.

People who reorganise one file in nixpkgs should not be expected to check and adjust relative paths in all other files.

This is relevant as we'll soon see the great RFC140 migration.

Now that the hooks override is fixed, the the apple SDK should use this style aswell as it doesn't have this obvious issue. (It may still have less obvious issues.)

I'd prefer a full makeRustPlatform call.

I tried that, but it seems to not be overriding as expected.

nix-repl> (pkgs.makeRustPlatform {rustc = pkgs.rustc; cargo = pkgs.cargo; clang = pkgs.clang_17;}).bindgenHook.clang
«derivation /nix/store/j16048gsic45ijdpw82172pfxdz9nw2w-clang-wrapper-16.0.6.drv»

Am I doing it wrong?

Ah, makeRustPlatform doesn't take a clang arg but does accept arbitrary args, so it doesn't throw an error to do this.

I don't see another option short of refactoring makeRustPlatform then.

I really don't know how this all works together; doesn't rust internally depend on clang aswell? Shouldnt'y you need to override that aswell?

I'd like input of the rust people on this. It appears they were pinged already.

This is what we do for firefox:

Not sure if it also applies to this.

@Mic92 Thanks for you help, but it seems that it still doesn't work. Let me know if I'm using this wrong:

nix-repl> (pkgs.makeRustPlatform { inherit (pkgs) rustc cargo; stdenv = pkgs.overrideCC pkgs.llvmPackages.stdenv (llvmPackages.stdenv.override { cc = pkgs.clang_17; }); }).bindgenHook.clang
«derivation /nix/store/c9ym6jk1pf0bx62j29g51k00pp16zf9l-clang-wrapper-16.0.6.drv»

nix-repl> (pkgs.makeRustPlatform { inherit (pkgs) rustc cargo; stdenv = pkgs.overrideCC pkgs.llvmPackages.stdenv.override { cc = pkgs.clang_17; }; }).bindgenHook.clang
«derivation /nix/store/c9ym6jk1pf0bx62j29g51k00pp16zf9l-clang-wrapper-16.0.6.drv»

nix-repl> (pkgs.makeRustPlatform { inherit (pkgs) rustc cargo; stdenv = pkgs.llvmPackages.stdenv.override { cc = pkgs.clang_17; }; }).bindgenHook.clang
«derivation /nix/store/c9ym6jk1pf0bx62j29g51k00pp16zf9l-clang-wrapper-16.0.6.drv»

For context, this is what I want to achieve (this is the current solution in the code):

nix-repl> (pkgs.rustPlatform.bindgenHook.override { clang = pkgs.clang_17; }).clang
«derivation /nix/store/cxxk9njrx1zm5ynmsi0wyy9dv58h2zci-clang-wrapper-17.0.6.drv»

(Also, I do want clang 16, but I want to pin it; I'm just using clang 17 in the repl to make sure it is being overridden)

Is there something I'm overlooking?

Can we add a short comment why this isn't working or set platforms to just x86_64-linux?

I think @Atemu advocated for broken instead of platforms here: #287632 (comment)

As for why it's broken in linux_aarch64, I personally have no idea as I personally don't have any ARM machine to try it out. Judging from comments in the other PR, it seems to be an issue with bindgen that has already been resolved, but pgvecto-rs hasn't incorporated the changes yet; I'll add that as a comment.
As for darwin, I don't see any official builds from pgvecto-rs, but darwin is listed in the targets section of the rust-toolchain.toml file upstream, so in theory it should work. Again, I don't own any darwin device, so I can't really test this.

The breakage on aarch64 is essentially this bindgen issue, reported here for pgrx, which is the issue seen in the failed aarch64 build.

I'll update the comment with the issue link for pgrx since it's more relevant, thanks!