Nix Flakes | 859 Members | |
| 177 Servers |
| Sender | Message | Time |
|---|---|---|
| 8 Aug 2024 | ||
What is maybe strange a bit is that nix eval --raw and nix eval --raw '.?submodules=1' gives the same output for the Nix only and a different one for the NixOS. | 10:26:00 | |
| 9 Aug 2024 | ||
| 20:28:47 | ||
| 10 Aug 2024 | ||
| 03:50:12 | ||
| 11 Aug 2024 | ||
| Hi, while on my journey to improving in Nix(OS) is there anyone interested in reviewing a Flake of mine? Spotting some anti-patterns and such. | 15:10:23 | |
| For example, the flake contains lots of packages, because I use it to build conditionally different versions. I went with a modular approach:
| 16:41:18 | |
| * For example, the flake contains lots of packages, because I use it to build conditionally different versions. I went with a modular approach:
Which allows to run the packages like | 16:42:45 | |
Is this a bad approach or can I instruct nix flake {show,check} dive into the attributes? | 16:43:42 | |
| * For example, the flake contains lots of packages, because I use it to build conditionally different versions. I went with a modular approach:
Which allows to run the packages like | 16:43:52 | |
| * For example, the flake contains lots of packages, because I use it to build conditionally different versions. I went with a modular approach:
Which allows to run the packages like | 16:44:04 | |
| * For example, the flake contains lots of packages, because I use it to build conditionally different versions. I went with a modular approach:
Which allows to run the packages like | 16:44:28 | |
| * For example, the flake contains lots of packages, because I use it to build conditionally different versions. I went with a modular approach:
Which allows to run the packages like | 16:44:44 | |
| yeah you're not allowed to do that sorry | 17:27:36 | |
| sadly | 17:27:45 | |
| im wondering - are there any experiments on how to have a library system for derivations, dependencies and so on - preferably without suckering into pkgs.lib im looking for stuff to make more easy autoupdaters, service specs, state management | 18:45:55 | |
In reply to @emilazy:matrix.orgI mean, it works enough for my use case. :D | 20:00:59 | |
well, it doesn't work for nix flake check :) | 20:01:34 | |
| Is there a good reason, why it doesn't/cannot work? | 20:02:02 | |
| My Flake is part of a research into libs/pkgs, so I am ok with it not fitting 100% into the infra. | 20:02:50 | |
| Nix doesn't seem to be used much for supporting any version of lib, but the strictness and constraints feel like a good match for that use case. | 20:04:32 | |
| Especially, for research reproduceability. | 20:04:52 | |
Another thing: installCheck phase is ran when doInstallCheck is set to true according to https://nixos.org/manual/nixpkgs/stable/#var-stdenv-doInstallCheck, but not when cross-compiling. I can't get my installCheck phase to run in a flake that uses flake-utils. Is the cross-compiling kicking in? | 20:13:20 | |
I am building with nix build '#pkg.ver' therefore I am not really thinking I am cross-compiling. | 20:13:48 | |
In reply to @qu4pk4:matrix.orgthe schema forbids it. legacyPackages lets you put arbitrary data in, which is why Nixpkgs uses it | 20:15:37 | |
| qu4pk4: Eelco is working on a flake-schemas effort to make supporting various schemas in the the top-level outputs. Regardless, you can place a "lib" wherever you wish. Nixpkgs itself places "lib" output into the top-level of the flake. | 22:29:56 | |
| 12 Aug 2024 | ||
| Thanks | 07:44:21 | |
How to use passthru.tests for testing Flake package builds? My idea is to build static libraries and tests that the lib<name>.a indeed exists by compiling a simple source. | 07:45:44 | |
But pkgs.runCommand used in https://nixos.org/manual/nixpkgs/stable/#var-meta-tests-nixos does not result in a derivation and therefore both nix run and nix build complain. | 07:46:46 | |
Or are passthru.tests somehow ran automatically on nix bulid '.#<pkg>'? | 07:48:45 | |
| 11:34:31 | ||
| 16:59:15 | ||