Compile breaks with async-graphql v8.0.0-rc.1

[aumetra]

Describe the bug

This has to do with the symlink strategy for the vendored files. See, the askama macro expansion attempts to fetch something from its "canonical" path and produces this path, which looks fine!

/nix/store/xsslyz1min98f6vybfdgpmkzks0n2q4d-vendor-cargo-deps/c19b7c6f923b580ac259164a89f2577984ad5ab09ee9d583b888f934adbbe8d0/async-graphql-8.0.0-rc.1/src/http/../../../../../six525kx1s0sb6299l3d06j3nj59kidl-cargo-package-async-graphql-8.0.0-rc.1/templates/graphiql_source.jinja

..but if you realpath it, it fails with "no such file or directory" which seems weird! Because /nix/store/six525kx1s0sb6299l3d06j3nj59kidl-cargo-package-async-graphql-8.0.0-rc.1/templates/graphiql_source.jinja does indeed exist!

But then for a sanity check I went ahead and realpath'd just /nix/store/xsslyz1min98f6vybfdgpmkzks0n2q4d-vendor-cargo-deps/c19b7c6f923b580ac259164a89f2577984ad5ab09ee9d583b888f934adbbe8d0/async-graphql-8.0.0-rc.1/src/http/../../../../../ and actually got / as the result which seems wrong.

But if I change in the directory /nix/store/xsslyz1min98f6vybfdgpmkzks0n2q4d-vendor-cargo-deps/c19b7c6f923b580ac259164a89f2577984ad5ab09ee9d583b888f934adbbe8d0/async-graphql-8.0.0-rc.1/src/http and run realpath $(pwd) it resolves to /nix/store/six525kx1s0sb6299l3d06j3nj59kidl-cargo-package-async-graphql-8.0.0-rc.1/src/http and suddenly things become clearer.

The ../../../../../ works off of the real path, not the symlinked path which then transports it up to the root directory.

Well, I have no idea how this would be fixed but this is unfortunately a thing and is also reproducible if you just change into the symlinked directory and use bat to try to list any directory that bash actually autocompletes.

Reproduction

[can add upon request]

[aumetra]

Well, not sure if this is the right place to file this or whether an Askama bug report would be more in order but since other tools like naersk seem to handle this correctly, I thought I'd file here first

[ipetkov]

Hi @aumetra thanks for the report!

Wonder if this is a quirk with how cargo/rustc resolves symlinks with back references (i.e. whether paths are canonicalized before or after the back references are handled).

Do you mind sharing a repro if you have one?

This has to do with the symlink strategy for the vendored files

Just to make sure I'm understanding, are you using installCargoArtifactsMode = "use-symlink"; in your derivation configuration or is this referring to symlinks within the source itself? I'd also suggest try setting installCargoArtifactsMode = "use-zstd"; and see if that helps.

[aumetra]

It fails with both settings. Here is the repr: https://github.com/aumetra/crane-repr
It's only an empty Rust project with the rc.1 added, and the default simple flake preset.

I mention async-graphql but I believe this will be an issue with any dependency that uses askama.

[ipetkov]

Thanks for the reproduction I'm seeing the same issue!

Do you know how askama looks for templates? I tried to peek at their sources and came across this: https://github.com/askama-rs/askama/blob/f06df54c9c2e9902767c594ebeed659450140ed7/askama_parser/src/lib.rs#L1376

It seems like the logic assumes that the directory where the templates are stored shares a common ancestor with where the current working directory is found (as is likely very common for most people's setups!). However, when building inside of a Nix derivation, on NixOS at least, the build is checked out at something like /build/source, but the actual vendored sources show up under /nix/store/<hash>-vendored-deps/<hash>/<crate>-<version>/...

It's also incredibly suspicious to me that the error is off by two consecutive ../ and coincidentally /build/source/ also has two path components. So I wonder if this is a bug in how they search for paths but it only gets tickled on NixOS builds where the store and the build sandbox don't share any common path ancestors besides /