Beastwick18 / nyaa

A tui tool for browsing and downloading torrents
https://crates.io/crates/nyaa
GNU General Public License v3.0
380 stars 8 forks source link

Nix(os) nyaa build fails, "No hash was found..." #17

Closed Amatrelan closed 3 months ago

Amatrelan commented 3 months ago

Hello!

So it seems to be so that now that you switched to local version of transmission-rpc, nix no longer cannot get hash for it in 975c0c737bc9fc13c976c861df81bd096ed74a76.

I don't know how to exactly this could be fixed (not that much experience to produce rust packages for nix).

Workaround I can use now is that I pin nyaa before this commit but this might be something to look for how to fix.

https://github.com/NixOS/nixpkgs/blob/master/doc/languages-frameworks/rust.section.md There is some documentation about buildRustPackage, what you use in default.nix to build rust package can be helpful in this case.

     … while evaluating attribute 'passAsFile' of derivation 'system-path'

         at /nix/store/8s55w0927lh3mdbkxf434zb0c5hqsz8z-source/pkgs/build-support/trivial-builders/default.nix:69:9:

           68|         inherit buildCommand name;
           69|         passAsFile = [ "buildCommand" ]
             |         ^
           70|           ++ (derivationArgs.passAsFile or [ ]);

       … while evaluating derivation 'nyaa-0.1'
         whose name attribute is located at /nix/store/8s55w0927lh3mdbkxf434zb0c5hqsz8z-source/pkgs/stdenv/generic/make-derivation.nix:331:7

       … while evaluating attribute 'cargoDeps' of derivation 'nyaa-0.1'

         at /nix/store/8s55w0927lh3mdbkxf434zb0c5hqsz8z-source/pkgs/build-support/rust/build-rust-package/default.nix:101:10:

          100| } // {
          101|   inherit buildAndTestSubdir cargoDeps;
             |          ^
          102|

       … while evaluating derivation 'cargo-vendor-dir'
         whose name attribute is located at /nix/store/8s55w0927lh3mdbkxf434zb0c5hqsz8z-source/pkgs/stdenv/generic/make-derivation.nix:331:7

       … while evaluating attribute 'buildCommand' of derivation 'cargo-vendor-dir'

         at /nix/store/8s55w0927lh3mdbkxf434zb0c5hqsz8z-source/pkgs/build-support/trivial-builders/default.nix:68:16:

           67|         enableParallelBuilding = true;
           68|         inherit buildCommand name;
             |                ^
           69|         passAsFile = [ "buildCommand" ]

       … while evaluating derivation 'transmission-rpc-0.4.2'
         whose name attribute is located at /nix/store/8s55w0927lh3mdbkxf434zb0c5hqsz8z-source/pkgs/stdenv/generic/make-derivation.nix:331:7

       … while evaluating attribute 'buildCommand' of derivation 'transmission-rpc-0.4.2'

         at /nix/store/8s55w0927lh3mdbkxf434zb0c5hqsz8z-source/pkgs/build-support/trivial-builders/default.nix:68:16:

           67|         enableParallelBuilding = true;
           68|         inherit buildCommand name;
             |                ^
           69|         passAsFile = [ "buildCommand" ]

       error: No hash was found while vendoring the git dependency transmission-rpc-0.4.2. You can add
       a hash through the `outputHashes` argument of `importCargoLock`:

       outputHashes = {
         "transmission-rpc-0.4.2" = "<hash>";
       };

       If you use `buildRustPackage`, you can add this attribute to the `cargoLock`
       attribute set.
Amatrelan commented 3 months ago

Ok so with quick testing this can be fixed by changing in default.nix

# default.nix
  cargoLock = {
    lockFile = ./Cargo.lock;
    allowBuiltinFetchGit = true;
  };

But if you plan to publish to nixpkgs this is not accepted solution.

For usage outside nixpkgs, allowBuiltinFetchGit could be used to avoid having to specify outputHashes.

In case you plan to publish to nixpkgs then you need to specify hash, ex:

# default.nix
cargoLock = {
    lockFile = ./Cargo.lock;
    outputHashes = {
      "transmission-rpc-0.4.2" = "sha256-3na/LUlcCk1MTbFXMtugK8YiLMdwF3m8QnpSKl3B4I8=";
    };
  };

That is correct hash so it works, so you can use that to run it.

You import pkgs in default.nix so actual path for lib.fakeHash is pkgs.lib.fakeHash. And to test it works, you can run nix run on root of the repository and it builds it and runs.

Beastwick18 commented 3 months ago

Ah good catch. I'll admit I don't have hardly any experience with Nix, and support for it was added by someone through a PR. I've been looking more into it recently though and I'm thinking about getting it put up on nixpkgs once I understand a bit more about it.

I've just verified that the outputHashes fix works, and for the meantime I'll use that as the solution. The reason I've switched to my fork of transmission-rpc is becuase the upstream version seems to not be maintained very actively.

I'm also unsure if nix packages usually locks to a specific version of whatever package they are building (like if default.nix should be locked to latest version v0.8.1).

For now, I'll close this issue with commit 8e57af6 which should fix it. Thanks for pointing this out 😄

Amatrelan commented 3 months ago

Local (in this repo) changes

Well to my understanding in default.nix version should point to correct version what it should download. But there is ways to take it from Cargo.toml, how yazi does it, you can change your version defined in default.nix with that solution if you want to use version from Cargo.toml.

In default.nix you don't need to specifically lock to version (but keep updated version what is in Cargo.toml), locking is done in nixpkgs side. Nixpkgs is immutable so it wont fetch "random" version, only what is specified, so when you update your package version and want nixpkgs have latest you need to make pull request to nixpkgs with updated hashes and revision.

Nixpkgs

In nixpkgs when source data is downloaded from github, it uses tags for it, fetchFromGithub is way to do it, yazi nixpkgs.

Here is ruff little simpler than yazi because yazi has unwrapped version with normal version.

Beastwick18 commented 3 months ago

Thanks for the insight :)

I think for now I'll save myself the headache of using a fork of transmission-rpc and stick to the latest version. If an issue comes up from lack of maintenance I'll find a workaround.

I'll try to have a locked version up on nixpkgs for this upcoming release, and keep the non-locked version still up on the repo.

Also, thanks for the examples. I'll try and get a more complete nix build that will be suitable for nixpkgs