Change:
{ lib, fetchgit, fetchzip }: { owner, repo, rev, name ? "source" <del> , fetchSubmodules ? false, private ? false </del> <ins> , fetchSubmodules ? false, leaveDotGit ? null , deepClone ? false, private ? false </ins> , githubBase ? "github.com", varPrefix ? null , ... # For hash agility <del> }@args: assert private -> !fetchSubmodules; </del> <ins> }@args: </ins> let baseUrl = "https://${githubBase}/${owner}/${repo}"; passthruAttrs = removeAttrs args [ "owner" "repo" "rev" "fetchSubmodules" "private" "githubBase" "varPrefix" ]; varBase = "NIX${if varPrefix == null then "" else "_${varPrefix}"}_GITHUB_PRIVATE_"; <ins> useFetchGit = fetchSubmodules || (leaveDotGit == true) || deepClone; </ins> # We prefer fetchzip in cases we don't need submodules as the hash # is more stable in that case. <del> fetcher = if fetchSubmodules then fetchgit else fetchzip; </del> <ins> fetcher = if useFetchGit then fetchgit else fetchzip; </ins> privateAttrs = lib.optionalAttrs private { netrcPhase = '' if [ -z "''$${varBase}USERNAME" -o -z "''$${varBase}PASSWORD" ]; then

Discussion:
Describe the bug When attempting to with the option set, the fetcher within will be unless the option is also set. To Reproduce Steps to reproduce the behavior: the following derivation (not picking on nix-script, it was just a handy, small example): Expected behavior should force to be used as well. Notify maintainers Metadata system: host os: multi-user?: sandbox: version: channels(root): nixpkgs: Maintainer information:
Note that is (hopefully) on its way out anyway:
The reason why I noticed it is because I was in the process of adding leaveDotGit to a package that (newly) requires this ability to extract the git hash during compilation. However, if you know of a way to handle this better I'm all ears. (Up to this point, I have just been disabling the inclusion of the git hash from the compile. But I can't just fake the hash or exclude it anymore, due to server verification.)
the preferred solution is: I was in the same situation previously and just to build without git.
Unfortunately, I can't seamlessly workaround needing in this case. Given I need the commit hash for a given tag. My options are, near as I can tell: upload the code to one of my personal websites or to my fork of the project for every release of the main code (Not easily verifiable that I haven't changed anything, extra steps in updating, I'm now a major point of failure) the CMake to not check with git, and provide the revision manually via a nix variable for every update (brittle, and I doubt the author would be happy about that, considering that he's going out of his way to ensure that the code that contributes to the project is not changed in someway). use leaveDotGit.
I also thought that 1. and 2. were infeasible but when the hash had changed for the third time within a few weeks I decided to just try and ask whether the maintainer would accept a patch to build without git. The case I made in this situation was “building from the release tarball I downloaded via GitHub fails”. That's probably better than saying “my exotic package manager can't deal with non-determinisitic directories” which might fall on deaf ears.
So for background, the package in question is .

Recently, katago has begun allowing users to contribute training games to the project, so as to develop stronger and more robust go AI. One of the checks that they implement, as a sanity check to ensure you're not accidentally or intentionally sending bad training data, is they check your git revision at compile time and compile the hash and whether or not the tree is marked as dirty into the client. They've had an option to since before I initially packaged katago for nix, and I've been using that option up until now for all builds. However, if you want to contribute to training, this is not an option because of the server side check. I've actually already implemented both options 2 and 3. (I implemented 2 before I knew that leaveDotGit existed.) So either way is OK by me. I've had 2 people tell me leaveDotGit was ok in this case, and 2 people tell me it's a horrible idea, and I'm sure this will be re-litigated whenever katago releases v1.7.1 and I make a PR.
How does it detect the revision? It's likely calling or something like it. The easier option, in that case, it to simply put a fake git command in the build inputs that just prints the current revision. Incidentally, I did this only a few days ago, you can take a look here: .
The command is: Cool idea. I could potentially do the fake git as shell script thing. But I still have the problem of needing the revision ID and not having an easy way to get that from the version information.
If you don't want to put it manually at each update, you could do