Fediversity/meta
13
3
Fork 4
Code Issues Pull requests Projects Releases Packages Wiki Activity

more comments on developer notes

Browse source
This commit is contained in:
Valentin Gagarin 2025-05-06 15:24:23 +02:00
parent b273853121
commit 9f9723ea62
1 changed files with 1 additions and 0 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

1
meeting-notes/2025-05-06 developer sync.md
View file

@ -11,6 +11,7 @@
- very similar to what we're doing, and similar to ngi.nixos.org it tries to solve the problem that NixOS doesn't have its own notion of application, which is the main barrier to entry - very similar to what we're doing, and similar to ngi.nixos.org it tries to solve the problem that NixOS doesn't have its own notion of application, which is the main barrier to entry
- we should probably try to converge on an upstream RFC, because multiple groups seem to be duplicating (and doing slightly divergent) work - we should probably try to converge on an upstream RFC, because multiple groups seem to be duplicating (and doing slightly divergent) work
- @kiara: i recently played with snowfallorg's GUIs nixos-software-center and nix-configuration-editor again. the former tries to do an app store for nixpkgs (including icons for some applications), but was based on a categorization no longer followed since RFC 140 (which introduced `pkgs/by-name/`), tho it seems the more recent categorization effort (RFC 146) might revive such discoverability again. on efforts toward discoverability, we should also file flakehub there. if i look at ngi.nixos.org tho, i think what they do well there is discoverability of option modules / services - making me wonder what we mean when we say application here. if i were to then think about how to generalize that, i would look into using `.package` defaults to explicitly associate packages with `programs` / `services` defaulting to them, such that tools like search.nixos.org would link from `services.nginx` to package `nginx` and the other way around. hopefully, that could achieve something like NGI's associations at nixpkgs scale. - @kiara: i recently played with snowfallorg's GUIs nixos-software-center and nix-configuration-editor again. the former tries to do an app store for nixpkgs (including icons for some applications), but was based on a categorization no longer followed since RFC 140 (which introduced `pkgs/by-name/`), tho it seems the more recent categorization effort (RFC 146) might revive such discoverability again. on efforts toward discoverability, we should also file flakehub there. if i look at ngi.nixos.org tho, i think what they do well there is discoverability of option modules / services - making me wonder what we mean when we say application here. if i were to then think about how to generalize that, i would look into using `.package` defaults to explicitly associate packages with `programs` / `services` defaulting to them, such that tools like search.nixos.org would link from `services.nginx` to package `nginx` and the other way around. hopefully, that could achieve something like NGI's associations at nixpkgs scale.
- @fricklerhandwerk: yes, leveraging the `.package` association would be an 80/20 shortcut to improve search.nixos.org, but ultimately it's a cludge until we have a proper data model for applications.
- investigated https://github.com/ibizaman/selfhostblocks - investigated https://github.com/ibizaman/selfhostblocks
- it's not fully mature yet, but seems usable and would help us plug different e.g. auth, secrets, or storage backend if we adopt it - it's not fully mature yet, but seems usable and would help us plug different e.g. auth, secrets, or storage backend if we adopt it
- @kiara: big fan here, already indicated to pierre i'd be down to help out as shepherd once he formally files the proposal as RFC - @kiara: big fan here, already indicated to pierre i'd be down to help out as shepherd once he formally files the proposal as RFC