I’ve been told this has been discussed before, but I haven’t found the discussion yet.
Once upon a time, I went browsing for games that had been packaged for NixOS, by looking in nixpkgs/pkgs/games. With the advent of pkgs/by-name, this is going to stop working.
I’d like to preface this by saying that discoverability isn’t necessarily a primary goal of nixpkgs, so I think it’s acceptable to have a not-great story here, and prioritise serving people who already know what they want
But for those who don’t, here are some thoughts:
It feels like it would probably be pretty easy to add a tags field to meta. You could imagine either making it a freeform set / list of strings, or limited to some centrally-managed “approved” list of tags with clear meanings.
Tagging existing software is obviously a big undertaking. Can we skip doing the backlog for now, and tag incrementally? Unfortunately I think not really: you probably won’t bother searching by tag at all if it only returns like half of the packages that ought to have the tag. It feels like a system like this would need to have a high coverage rate to be worth bothering with at all.
Obviously, tags that can be inferred from existing information are great. NixOS Search already allows narrowing results by maintainer, “package set”, platform, and license. (Weirdly, these filters can only operate with a search term, it seems, not alone. But probably that would be easy to fix.) If it were possible to infer things like “is this package a game?” automatically, that would be ideal, but I think it probably isn’t.
Since “any tags at all” is the highest priority, over and above “perfect tags”, this makes me wish we could set an extremely low bar for package tagging, like a wiki-style situation where anyone can contribute, and contributing doesn’t mean making a PR and getting it approved but just clicking a few buttons.
I almost want to add it to the aforementioned package search website? But the package search website probably really likes not having much in the way of data storage or user management. Still, some third-party service would be the least invasive / annoying way to test viability of this idea, though it might of course be so out of the way that it can’t really keep up.
Not to be That Guy, but I wonder if running an LLM over the package name and description would often enough get us tags that were good enough to make a start? Perhaps we could explicitly mark them as unvetted guesses in some way.
But then we have the question of what steady state we want, and whether the additional maintenance burden is worth the benefits even once you’ve paid the startup costs. I think it’s very easy to get carried away with this kind of thing, and add a bunch of niche tags that you imagined someone might use one day, but they in fact never do.
I guess a useful question, then, is what has already been tried out there in the world of software distribution? Do other distros or platforms have good discoverability tools to help people find new software or alternative software to solve their problems?
One decent starting place may be tagging things with the folder they were in prior to being moved to by-name, if they were moved. Probably some automation could be applied to do this in a treewide.
An enhancement? Sure. A simple enhancement? Probably not. This will require a massive tree-wide PR that categorises over one hundred thousand packages; not a small feat by any stretch of the imagination.
Okay, but do we have everything other than the actual categorisation? Are we ready to start adding categories to packages today, or is there still infrastructure we need first?
I was referring to just making the capability of adding categories to meta available (unless that is already done), I was not referring to the task of actually categorizing the nixpkgs tree, fwiw.
I’m amazed that this README tells you everything you’d want to know about the rfc process, except for how an approved rfc is put into action. GitHub - NixOS/rfcs: The Nix community RFCs
I would say it might be a good idea to lok at the people interested to join the categorisation team in the PR discussion / FCP announcement on Discourse, and try to actually create a team (I guess in the team-list.nix first as there any committer can merge it, I guess a GitHub mentionable team could be created once the initial team decisions are done).
Then the team needs to decide how much to add to the FreeDesktop.org application categorisation system («nothing» is not an answer as we want to be able to classify libraries too…)
I want to visit my 3D flesh-and-blood friends in my vacation. So I will not take any such from-scratch projects until the beginning of the next year.
Feel free to start this project without me. I can complain about the code not following the formatting guidelines later.
Looks like RFC was approved, merged, what happens next?
Since the RFC is merged, there is no need to argue for its relevance.
Just open your emacs instance and write some code.
Does categorization capability itself exist in nixpkgs? I’d yet to uncover it.
Nix itself exists As I proposed in the RFC, it is a matter of adding fields to meta.
That’s cool. My reaction intention is to share my personal view that if someone like myself is not deep in the mix of all of these nix/nixpkgs processes, it’s hard to understand what they are, what happens next etc.
You’re right! I ended up just using a bit of nix in a flake to create a way to categorize any existing package from any other flake, with my own categories.
