As part of a recent Nixpkgs Architecture Team (NAT) effort (feedback welcome in issues or on #nixpkgs-architecture:nixos.org), we’re trying to get an idea for how many people rely on the directory navigation feature in GitHub to get to nixpkgs’ package definitions. This feature allows you to navigate to directories and files by clicking on them from file listings. This is what it looks like to use this feature to navigate to a nixpkgs’ package definition:
On average, how often do you use this GitHub feature to get to nixpkgs’ package definitions?
Every day
Every week
Every month
Very rarely
Never
0voters
If you are using this GitHub feature to get to nixpkgs package definitions, what are your use cases? (if you aren’t, don’t answer this part)
Creating a shareable URL to a package definition
Checking out the definition of a package to reuse its definition or a part of it
Checking out the definition of a package to debug its build failing
Browsing to check out similar packages to one you already know
Browsing to check out packages of a specific category (such as pkgs/games, pkgs/applications/office, etc.)
Browsing out of curiosity as to what packages there are in nixpkgs, perhaps finding something interesting and new
Modifying a file online using GitHub’s edit or VS code feature
Other (leave a reply or an existing one)
0voters
Note that we’re only asking about whether you’re using this specific GitHub feature for doing these things, not whether you use other means to do these things
I never use the directory structure to navigate the repository on github, and always rely on the basic fuzzy file search (button Go to file, shortcut t).
The same when I’m editing files locally, relying on fzf’ fuzzy search to find the file(s) I want.
I want to highlight the fact that I still think having the structure is important, if only to see in the fuzzy finder that I’m selecting the correct file, the one under ‘interpreter’ for example and not something under ‘application’ if I’m looking for a specific language tool.
If we have everything in one directory, we loose that ability to know what kind of thing I’m opening.
I do not use the GH file browser to find module or package files in nixpkgs, but in third party flakes.
For nixpkgs I use the package and module search and click on the respective links to get to the definition on GH.
Mostly I use this to then also link what I found in a chat to point out what causes problems, or what might be an example of what would solve someone’s problem.
This is interesting, especially for packages with simple derivations (eg: nix edit nixpkgs#bat), but when you run it on any Haskell executable package, the output is not particularly useful (eg: nix edit nixpkgs#neuron-notes).
I use this pretty much all the time when I’m working with Nixpkgs, for both package and NixOS module definitions. I almost exclusively use it through the ‘file finder’ interface, similar to an earlier commenter, so if I’m trying to find the Grub module I’d type t then maybe modgrub.
Although I mentioned I never use the directory structure to go around in nixpkgs, using the go to file fuzzy finder instead, I want to highlight the fact that I still think having the structure is important, if only to see in the fuzzy finder that I’m selecting the correct file, the one under ‘interpreter’ for example and not something under ‘application’ if I’m looking for a specific language tool.
If we have everything in one directory, I loose that ability to know what kind of thing I’m opening.
I usually use the emacs function search-forward in pkgs/top-level/all-packages.nix to find where i need to go. then emacs find-file-at-point which jumps you into the file.
I don’t think the major direction will change either but I was surprised that I missed it despite spending multiple hours a day contributing and browsing the community.
Blockquote
Although I mentioned I never use the directory structure to go around in nixpkgs, using the go to file fuzzy finder instead, I want to highlight the fact that I still think having the structure is important, if only to see in the fuzzy finder that I’m selecting the correct file, the one under ‘interpreter’ for example and not something under ‘application’ if I’m looking for a specific language tool.
If we have everything in one directory, we loose that ability to know what kind of thing I’m opening.
I use a local checkout with ripgrep and fzf (sometimes in a terminal, sometimes in an editor) when I have one available, but I use the GitHub web interface when I’m more casually browsing projects (PRs past and present) on mobile or just checking out what people are working on without doing any development for my own purposes.
I like it to be more consistent. Looking up an attribute requires looking in all-packages.nix and finding the right file. Having the filenames equal to the attribute name would make more sense to me. The categories that the current directory structure represents could also be encoded as meta information. Maybe a tags meta attribute that includes things like git, development, shell, gui, etc.
Not really waiting for a migration, but it would’ve been nice if it was more consistent.
Ah sorry, this was indeed mentioned earlier. It is fine when you’re on a system with Nix in the terminal, but when navigating GitHub or in a editor it would still be helpful.
That thing (github file browser thing) is so slow, that I keep a cloned nixpkgs on my machine and use fd or ripgrep. Cheaper and faster on both network and time.
an existing one)
