How to tell which nixpkgs was used to build a `result`?

1

I’m trying to figure out why I can’t get nix-build to produce the expected output. Is there some way to check which nixpkgs version is being used to build the project?

2

Do you mean which nixpkgs version is the “currently active” one that gets used by nix-build? That’s easy: nix-instantiate --eval '<nixpkgs>' -A lib.trivial.version.

About your issue: Your MR seems to be using stable’s staging. That doesn’t have the patch; only master’s staging has it.

1 Like
3

That’s at least not giving the result I expect. My project is using “https://github.com/NixOS/nixpkgs/archive/9c14978f845f33b152f722709caf42148580a30c.tar.gz”, but nix-instantiate --eval '<nixpkgs>' -A lib.trivial.version in the project directory reports “22.05.3373.13cbe534ebe”.

Huh? “master” and “staging” are both branches, how do I get “master’s staging”? Also, I tried git checkout 9c14978f845f33b152f722709caf42148580a30c && git grep pythonOutputDistHook in nixpkgs, and that has pythonOutputDistHook.

4

<nixpkgs> is the Nixpkgs from your environment. Your project is set up to have one specific version pinned via IFD. In your case, you could do nix-instantiate --eval ./nixpkgs.nix -A lib.trivial.version.

staging is the branch that will be merged into master via the staging-next process. nixos-21.11 has its own staging branch that works similarly.

Your commit confused me because it mentioned nixos-21.11 in the name but the commit it fetches is from master’s staging.

Could you try nix-build ./nixpkgs.nix -A python310Packages.pytest.dist?

5

Cool. I just tried that, and got a completely unexpected answer:

$ cat nixpkgs.nix 
import
(
  fetchTarball {
    name = "nixos-22.11.staging-next.9c14978f845f";
    url = "https://github.com/NixOS/nixpkgs/archive/9c14978f845f33b152f722709caf42148580a30c.tar.gz";
    sha256 = "1ipr02a8pvln9spf7c52wdvyzz0yhpkivcyjsc9ahxfpapkhj5i8";
  }
)
{}
$ nix-instantiate --eval ./nixpkgs.nix -A lib.trivial.version
"22.11pre-git"

I have no idea where that name is coming from, but it’s not allowing me to figure out whether I’m actually using “https://github.com/NixOS/nixpkgs/archive/9c14978f845f33b152f722709caf42148580a30c.tar.gz”.

6

Nixpkgs is a single repo, so it can’t have two branches with the same name. I guess you mean the staging, staging-next, and staging-21.11 branches.

Oh, the “nixos-22.11” bit in the name is just a convention I’ve picked up from nixpkgs to name things which will be part of 21.11 with that name. Basically the same as the names in Channels for NixOS project(s).

7

Try invalidating the hash again to make sure you’re getting the correct commit and not some other source in your Nix store.

8

I guess you mean like this?

$ sudo nix-collect-garbage --delete-old
[…]
$ nix-build ./nixpkgs.nix -A python310Packages.pytest.dist
/nix/store/blkds5w1wcv1y5pn7z5dzisazwhprn7h-python3.10-pytest-7.1.3-dist

I do not understand this result. I don’t have pytest in my path or in nix-env --query, so I don’t know why it’s not being rebuilt.

9

Yes, with “nixos-21.11’s staging” I meant staging-21.11.

Sorry, I didn’t read properly. You said 22.11, not 21.11.

That also means your nixpkgs and its hash is likely valid.

10

Welp, then I have absolutely no idea how to proceed. Neither how to invalidate /nix/store/blkds5w1wcv1y5pn7z5dzisazwhprn7h-python3.10-pytest-7.1.3-dist, nor which nixpkgs I’m actually using.

11

Rebooted on unix.stackexchange.com to avoid the forum effect.

12

Unrelated, but ooi, what’s the forum effect? People not reading old posts with no resolution? Why does posting on a different forum help with that?

As for your problem, what are the chances you could share the full project, at least the nix bits? Only way I can imagine seeing the symptoms you have is if you juggled multiple nixpkgs versions into your build somehow and are overlooking one.

13

Basically, if there’s a long thread with no resolution, people are unlikely to a) read the whole thing, b) realise there was no resolution and rewind their understanding of the issue, and c) answer the initial question as stated.

A bunch of reasons:

  1. Stack Exchange sites are not forums. The primary objective of SE is to get a resolution to the original question as stated, so any and all verbose back-and-forth discussion is likely going to happen in very de-emphasized comments rather than in answers.
  2. Comment threads are likely to be shunted to a different place if they get too long, helping new readers to focus on the original question.
  3. SE has votes and flagging to make sure useful answers percolate to the top rather than staying hidden in the middle of a discussion. The Discourse :heart: just doesn’t compare in impact.
14

For topics in the “help” category, you can elect a reply as the solution, this marks the topic as solved and highlight the solution :+1:t3:

1 Like
15

I already did, but in the linked post.

I know, it’s not been resolved though. Unfortunately, anyone else seeing this topic will have to read through 15 posts to figure that out for themselves.

1 Like
16

No, that deletes all unreferenced paths in your Nix store. I meant to invalidate the hash of the Nixpkgs fetch. It seems it’s correct though.

So, it works? There’s the output path you wanted, no?

1 Like
17

No, I wanted to know how to apply this to my own code. It took many, many hours and nix - How to use the new `pythonOutputDistHook` in nixpkgs? - Unix & Linux Stack Exchange before it crystallised that all I had to do was nix-build -A dist. That was not obvious to me from reading the comments. I had no idea the “.dist” part of the command was the magic sauce, and once I thought that might be the case, I first tried a few things like vcard.dist and .dist before having the luck of landing on the right incantation.

Basically, it’s resolved now, but not in this thread.

I hope this doesn’t sound too grumpy - I’m really grateful for the time you’ve taken to help out!

1 Like