[wip] create categories.nix #325357
[wip] create categories.nix #325357
Conversation
github-actions
bot
added
8.has: documentation
ofborg
bot
added
10.rebuild-darwin: 0
As a proof-of-concept for NixOS/rfcs#146
As a proof-of-concept for NixOS/rfcs#146
As a proof-of-concept for NixOS RFC 146 Double wip because it lacks the descriptions.
AndersonTorres
changed the title
| { lib }: | ||
|
|
||
| let | ||
| mainCategories = { |
There was a problem hiding this comment.
Don't you think this list is way, way to long to start with?
There was a problem hiding this comment.
This is just the Appstream listing.
There was a problem hiding this comment.
was this generated via script, then?
There was a problem hiding this comment.
Nope, it was generated by Emacs keyboard macros! :)
| instantMessaging = { | ||
| name = "instantMessaging"; | ||
| description = '' | ||
| ''; | ||
| relatedCategories = []; | ||
| }; | ||
| ircClient = { | ||
| name = "ircClient"; | ||
| description = '' | ||
| ''; | ||
| relatedCategories = []; | ||
| }; |
There was a problem hiding this comment.
Also I question the usefulness of copying the entirety of xdg. For example those two are just chat.
There was a problem hiding this comment.
Along the conversations of RFC 146, it was cited the integration with Appstream.
| ''; | ||
| relatedCategories = []; | ||
| }; | ||
| java = { |
There was a problem hiding this comment.
or why java? Do we then also need rust, go, ruby, etc? Collecting such detailed metadata is not making this effort easier.
There was a problem hiding this comment.
Maybe it was from a time Java applets were very typical. And, we know, backwards compatibility...
| description = '' | ||
| Description of category | ||
| ''; | ||
| relatedCategories = [ related01 related02 . . . ]; |
There was a problem hiding this comment.
I think this representation of category relations is too ambiguous. Do I add parent categories here? Children? Siblings? An example would be helpful.
Categories naturally have a forest shape. As I proposed in NixOS/rfcs#146 (comment) I think we can represent relations as parentCategory = cat1, then we can flatten the relations as needed in a post-processing step.
parentCategories = [ cat1 cat2 ] (plural) would also work, but I think we can restrict ourselves to a singular parent since packages can have multiple categories.
Alternatively, I propose to omit relations until we have a clearer picture of how categories are used.
There was a problem hiding this comment.
I think these will be parent categories, in the end; it might end up being a DAG not a forest.
I agree, though, that cutting the not-strictly-necessary stuff at first is often good, and adding the relation records will not become harder with time.
| { lib }: | ||
|
|
||
| let | ||
| mainCategories = { |
There was a problem hiding this comment.
I think we can remove the mainCategories/additionalCategories distinction, especially if we establish a hierarchy as described in https://github.com/NixOS/nixpkgs/pull/325357/files#r1668350336. Furthermore, RFC146 (section "Semantic Details") establishes "most important" categories to be a package-level concept.
There was a problem hiding this comment.
The intention is not to establish a hierarchy, but to reflect Appstream.
There was a problem hiding this comment.
A priori, for automatic conversion one doesn't need all FreeDesktop.org categories to have different images…
There was a problem hiding this comment.
In the sense of a function mapping preimages to images. Automatically deciding something based on FreeDesktop.org categories might be useful even we decide the same thing for specific different categories.
There was a problem hiding this comment.
Image in the sense of mathematical functions? "We do not need a bijective mapping between Appstream and Nix Categories"?
There was a problem hiding this comment.
Yes.
We cannot have a surjective mapping (which would mean no non-FreeDesktop.org-matching categories) because Appstream is about apps and we have some very non-apps packages (and Freedesktop.org categorisation is for application launchers even before Appstream).
We are not obliged to have an injective mapping either, as some distinctions can be ignored or not ignored as a policy decision.
AndersonTorres
changed the title
|
I think the actual category set will get merged as maintained by the categorisation team; maybe the team can be added separately first, though. |
|
I believe this PR accomplished its intent of bringing a proof-of-concept. So I will close this. |
|
This pull request has been mentioned on NixOS Discourse. There might be relevant details there: https://discourse.nixos.org/t/tagging-categorising-nixpkgs/55396/16 |
Description of changes
Restarting #230439
POC of NixOS/rfcs#146
Edit
For those interested in commenting this PR: I am not planning to merge it as-is.
It was/is a mere proof of concept, useful for discussions, given that I believe some discussions are better substantiated by code.
Things done
nix.conf? (See Nix manual)sandbox = relaxedsandbox = truenix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage./result/bin/)Add a 👍 reaction to pull requests you find important.