| 9 Jan 2026 |
 guiniol | Took a while because I forgot to add cache.nixos.org as a substituter initially but now it's all done and it all looks good. Thanks everybody! | 08:36:30 |
 donn | anyone know what to do when nix run 'nixpkgs#nixpkgs-review' -- pr --post-result 477797 just posts "nothing to build" | 12:58:52 |
| donn | * anyone know what to do when nix run 'nixpkgs#nixpkgs-review' -- pr --post-result 477797 just prints "nothing to build" | 12:59:11 |
 K900 | Why would you need to nixpkgs-review a PR that adds a singular package | 12:59:31 |
| donn | just to prove it builds on aarch64-darwin before the CI gets to it | 13:00:09 |
| K900 | Just build it manually? | 13:00:33 |
| donn | is nixpkgs-review for packages with a lot of dependencies? genuinely asking i may have a mistaken impression about it | 13:01:56 |
| donn | * is nixpkgs-review for packages with a lot of dependents? genuinely asking i may have a mistaken impression about it | 13:02:10 |
| K900 | nixpkgs-review is for testing everything that depends on the package still builds | 13:02:37 |
| donn | gotcha | 13:02:45 |
| K900 | It makes no sense when you're adding a leaf package | 13:02:50 |
| K900 | Except the comments look pretty and some people have github actions set up to spam that shit on their PRs | 13:03:01 |
| K900 | Which is bad, by the way | 13:03:05 |
| donn | oh. darwin wasn't even in the supported systems. that would do it | 13:07:46 |
 sterni | Is there prior discussion on making the default Nix version for Nixpkgs configurable I can read up on? This is obviously a long standing problem since you always wind up with multiple Nix versions if you don't stick to pkgs.nix even if it's not strictly necessary (due to use of the API etc.) and more urgent with Lix existing now… | 17:44:16 |
| K900 | This was never a thing I believe | 17:45:38 |
| K900 | Well technically that's why nixForLinking was introduced | 17:45:47 |
| K900 | But eventually we'll probably see things targeting the Lix APIs instead | 17:46:12 |
| K900 | Which means there will have to be a lixForLinking I guess? | 17:46:24 |
| K900 | But like fundamentally you can't just overlay { nix = final.lix } and have that work | 17:46:38 |
| K900 | Because the APIs have diverged enough | 17:46:43 |
| sterni | what I was thinking about to begin with was the low hanging fruits, i.e. just stable-ish CLI use. E.g. if you have pkgs.nix in your wrapper for prefetch scripts etc. | 17:49:15 |
 raitobezarius | for flags, we are not planning to break existing CLI flags (except if completely buggy / no usage / etc.) in existing CLIs | 17:49:44 |
| sterni | We kind of need a config option for a mostly compatible use of Nix precisely because you can't overlay pkgs.nix properly anymore. | 17:49:49 |
| raitobezarius | we would do nix4 for the new CLI | 17:49:49 |
| K900 | IMO CLIs should really just use the ambient nix cli | 17:49:48 |
| K900 | * IMO CLIs should really just use the ambient nix CLI | 17:49:50 |
| raitobezarius | for outputs in CLI, we would introduce flags for versioning the outputs | 17:49:59 |
| sterni | Yes, this seems to be the best option at the moment. | 17:50:11 |
| raitobezarius | but then they absolutely need versioned output flag they can rely on | 17:50:35 |
