Poll: How often do you navigate through directories on GitHub to get to a nixpkgs package file?

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:

clip

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

0 voters

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 :heart: an existing one)

0 voters

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 :slight_smile:

4 Likes

I recently learned about nix edit nixpkgs#hello to view a definition :exploding_head:

23 Likes

Most often to review definitions for security concerns before running them.

Also FWIW, I’d normally get there by googling something like “github nixpkgs hello” rather than manually clicking through github directories.

TIL about nix edit nixpkgs#hello though, so probably will rarely visit the github for this again! Thanks @Solene!

4 Likes

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.


EDIT: (extract of my reply later here)

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.

13 Likes

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.

6 Likes

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).

2 Likes

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.

1 Like

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.

2 Likes

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.

1 Like

I am not sure how representative that poll is and how many people missed it like me.

2 Likes

@Sandro I reopened the poll, feel free to vote. Though it was open for about a month and has a lot of responses, I don’t think much will change

1 Like

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 agree with this comment from @bew

By the way, there is now a “New code view” beta test.

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.

nix edit. Give it a try: nix edit nixpkgs#neofetch.

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.

1 Like

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.

2 Likes