I’m looking for feedback on how I can improve this working nix expression for Deno.
There is an open issue on GitHub(#78461) for packaging Deno, and below is an expression that successfully builds it from source (warning: takes 49 minutes on my machine to compile!):
There are multiple hacks going on here:
The cargo package
rusty_v8 let’s users set a
CLANG_BASE_PATH environment variable to looks for both
llvm-ar binaries. The
llvm-with-clang derivation is a workaround for this lookup.
Also note that, the version of clang & llvm with this hack are different lol:
[/nix/store/*-llvm-with-clang]$ ./bin/clang --version clang version 8.0.1 (tags/RELEASE_801/final) Target: x86_64-unknown-linux-gnu Thread model: posix InstalledDir: /nix/store/bv17ssmbij00i2xdq4s1xkld1ix2g3b3-clang-8.0.1/bin [/nix/store/*-llvm-with-clang]$ ./bin/llvm-ar --version LLVM (http://llvm.org/): LLVM version 7.1.0 Optimized build. Default target: x86_64-unknown-linux-gnu Host CPU: skylake
but it works so
Unfortunately, 10 of the tests fail to pass with
test result: FAILED. 211 passed; 10 failed; 0 ignored; 0 measured; 0 filtered out
What’s the common approach here when dealing with packages who’s test cases are, well, not friendly?
I don’t think this is an issue with Nix at all — see comments above
This is more of a maintenance nightmare — whenever anyone updates
rev in deno’s
fetchgit, they have to make sure that these re-created files are in-sync with the current deno codebase.
I’d love to bring Deno to Nix, but I can’t realistically open a PR. This is my first Nix package for a 3rd party project, and, I don’t use GitHub.
The goal is that someone can help champion this into the
nixpkgs repository on my behalf (after the hacks are cleaned up a bit), and, I learn a heck-of-a-lot from interacting with folks on this forum
Help a Nix novice today!