Template talk:Nixos:package

Deletion candidate

Completely disagree about deleting this template.

• Template:Nixpkgs links to the github page. That is not user friendly. Someone should not have to read source code files to understand module package options and descriptions. The UI on search.nixos.org is much more user friendly.
• It is not LMGTFY as packages are not always indexed on search engines. It took me a long time as a NixOS user to learn about the existence of search.nixos.org, it should not be assumed that everyone is familiar with this service.
• This is one of the most used templates on the wiki.

If anything, in my opinion we should be encouraging {{{1}}} over the use of Template:Nixpkgs unless if there is a specific reason that a user would find the source code important. Pigs (talk) 05:31, 8 June 2025 (UTC)

I would agree with you if the core of the argument was implemented properly on the search page. I am 100% on the same page that we should aim for readability and user friendliness here. But that's exactly why I don't think this template hits the mark on that front.

Someone should not have to read source code files to understand module package options and descriptions.

That's exactly the thing: the search functionality doesn't expose package options at all. The only way an user can learn about them is by reading the source code. Is that ideal? Of course not, but it is currently what it is.

As for the description part, I would say in 99% of the time when this template is used, it's used either in the corresponding package's article, or in a context where adding the package description is trivial.

For the second point, I think we should definitely be improving the main page itself to point the user to the search functionality as an option, as well as improving NixOS search. And on top of that, we probably want a First steps using NixOS page or similar to really drive this point home.

For the third point, I don't think a package's current usage is an argument for or against its deletion (other than on technicality: we'd of course want to modify all pages using this template to point to the new one). However, do note, it's only used in 24 pages, hardly an edit burden. DoggoBit (talk) 17:10, 8 June 2025 (UTC)

When I was writing my reply I kept mistakenly was thinking of the Nixos:option template which is much more of a useful and popular template. My mistake.

You are right that currently linking to a package on search.nixos.org does not provide as much information as it should. (It's more on the package maintainers to provide useful descriptions (like the docker maintainers do) than it is of a missing feature from search.nixos.org.

I still hold my position that linking to ghc is a way better user experience than linking to

⤟︎

This template is a candidate for merging with Template:Nixpkg. They seem to be duplicates. Further information may be found in the relevant discussion page.

pkgs/development/compilers/ghc/common-hadrian.nix both in terms of a maintainer and as an end user.

To me, linking to source code is a bad option when there is a friendly interface that displays all the relevant information such as programs provided, current version, outputs, and if a user wants to, there is a link to the source code on the search result. How fast can you find that information on the Nixpkgs link? The version isn't even mentioned in the source code of the main file for GHC. Pigs (talk) 21:31, 8 June 2025 (UTC)

Yeah, I'm 100% with you on this, and {{nixos:option}} is nowhere near being at risk of not making the cut here haha (other than a saner renaming). That template is a million times more useful than this one.

I'm thinking here very much from a user perspective: If I'm being served a link off the wiki, I would want it to contain more information than the wiki itself, right? Otherwise there's no point linking somewhere external in the first place. That's why I don't think this template makes sense with the current search interface at all, it's less useful than the page it's being used on. However, linking to the nixpkgs file is more usefu than the page, because the user can see the additional build options that package may have.

If we're talking about having _a_ link to the corresponding Nix package entry, we could implement this via {{infobox application}} (or the corresponding one) further down the line DoggoBit (talk) 21:55, 8 June 2025 (UTC)