Pinning nixpkgs in documentation examples?

I have three questions regarding documentation and pinning nixpkgs.

  1. I wonder how the examples should be use refer to nixpkgs. declares that <…> is a anti-pattern.
    I think this makes sense in the context of the statement.
    But examples should be also concise, so I prefer nixpkgs = <nixpkgs>.
nixpkgs = <nixpkgs>;
nixpkgs = builtins.fetchTarball "";
nixpkgs = .;
nixpkgs = builtins.fetchTarball ""
nixpkgs = builtins.fetchTarball ""
nixpkgs = builtins.fetchTarball ""
nixpkgs = builtins.fetchTarball ""
  1. I wonder about the difference between those two options:
nixpkgs = builtins.fetchTarball "";
nixpkgs = builtins.fetchTarball ""
  1. Where we should put single entry in the “reference” section on
    Pinning Nixpkgs — documentation
    I think its not really a reference but useful information that could be extended maybe even into a tutorial, anyone who disagrees on this direction?

They refer to two different git tags of the nixpkgs repo…

I don’t understand the question

I edited the example to reduce the confusion.

nixpkgs = builtins.fetchTarball "";
nixpkgs = builtins.fetchTarball "";

the point i wanted to make is that there are two path to get the same “archive”.

the third point is about documentation improvement to make nix more accessible.

Good question, and I would also like to see a compelling answer (and would be happy if you elaborated one given you find it important enough to spend time with), but it’s not high priority: we have many other things where spending effort has much more impact. One example being delivering a good overview on the situation and trade-off we have with adopting flakes. Details like these are important as well though, so (again, if you care enough) open a pull request with a suggestion for an answer and reasoning good enough to preempt bikeshedding. An issue to lead a discussion might grab more attention than it’s worth.

If you mean where to put such an answer - I’d say it depends on the format. If we go by The Documentation System, we have as options: tutorial, guide, explanation, and reference.

Reference belongs to the manual, and I would not object moving that section out of and finding a spot in the manual. Telling how to do it best would be something for a guide or a collection of brief encodings of best practices or antipatterns on, referencing manual. Not sure what a tutorial looks like, but we haven’t really defined a place for explanations yet, where in this case I would imagine explaining why the different options even exist and some reasoning why to use one or another. Having such a write-up is certainly valuable, and having a deterministic place to put and find them would be great. I made a proposal to have an „optional“ section in the guide structure, but I’m open to suggestions.

1 Like

maybe 22.05 is based on nixpkgs-unstable branch, while nixos-22.05 is based on nixos-unstable? if you’re using that for a nixos system, then go with nixos-22.05, if not then guess you can go with 22.05.

and i would recommend using flakes instead of that non-flake way because flake is a way better workflow when it comes to pinning, managing dependencies/inputs on other nix repositories.

Both “22.05.tar.gz” as well as “nixos-22.05.tar.gz” point to refs that GitHub transparently translates into tags and branches tips.

22.05 is a tag, nixos-22.05 is a branch.

The points to the commit of the branch of (or the first commit there after, I don’t remember exactly).

You rarely want to use the tag. As it is static, it will not even receive security updates.

Though I wouldn’t use the branches tarball directly either without pinning mechanisms that avoid accidental updates.


@NobbZ thanks after you said it seems so obvious.

@fricklerhandwerk ok i will make a suggestion for the first point:

Because examples should be simple they should not break on any system that is stable so should be good enough, concise and should cause little traffic to download packages.
I was on unstable until 22.05, I never had problems with a broken (base) system on either.
More complicated examples like the current example from actually need pinning, so they should be pinned.
In the context of my guide It’s enough to clarify this at the beginning and link to the “pinning reference”.

I keep a note for myself that the “pinning reference” needs some work.

Documenting flakes is a task that seem to be endlessly expandable :see_no_evil: .

i mean it is obvious from that perspective, but having a nixos prefix or not makes a difference in how they are tested, or include one thing or another. i don’t think anything not prefixed with nixos include nixos specific stuff like some nixos specific tests.

do you know from which branches do they base these branches on? nixos-unstable and nixpkgs-unstable?

Baseline for everything else is master.

From master the release-* are branched off.

Individual PRs are cherry picked into the release-* branches.

Hydra constantly builds current tip of active release-* and master branches. If this build succeeds relevant commits again are cherry picked into nixos-* branches. (This last step is overlay simplified for the matter of this post)

There should be answers on this in the maintainer section of the contributor guidelines, but there are not. The closest thing is maybe commit policy. @yuu would be great if you could seize the opportunity to encode what you find and learn right into the manual. @jonringer I remember there was a GitHub issue or something like that from last year or so where you roughly outlined the process, do you have a pointer?

Closest I can think of is Nix channels - NixOS Wiki. If we do add it, it should go into the nixpkgs manual.

1 Like

can’t give any ETA on this tho

Hosted by Flying Circus.