| 24 Oct 2023 |
Lorenz Leutgeb | * When exeucuting nix build github:NixOS/nixpkgs/nixos-unstable#hello I would like nix build to print the revision that it used, i.e. the hash that "nixos-unstable" referred to at the time of invocation, to have a reproducible copy-pastable output. There doesn't seem to be an option? How do I do that? | 20:25:15 |
pbsds | make an alias? | 20:26:33 |
pbsds | nix registry may be the place to look | 20:26:57 |
Lorenz Leutgeb | In reply to @pederbs:pvv.ntnu.no nix registry may be the place to look I'd like a solution that works both for flakes that are in the registry and for ones that are not. The requirement to know which revision was used isn't that crazy, is it? | 20:27:54 |
Lorenz Leutgeb | In reply to @pederbs:pvv.ntnu.no nix registry may be the place to look * I'd like a solution that works both for flakes that are in the registry and for ones that are not. The question which revision was used isn't that crazy, is it? | 20:28:03 |
Lorenz Leutgeb | In reply to @pederbs:pvv.ntnu.no make an alias? You mean a shell alias? An alias from what to what? I don't know an that gives me the output I want. I could call nix flake show right before/after I call nix build, but that's racy. | 20:30:00 |
pbsds | You use the resolved flake url in nix build | 20:53:01 |
Lorenz Leutgeb | One nice property of flakes is that I can address them as github:edolstra/hello, that's something I can remember as a human. This reference changes over time and is not reproducible. Whenever I call nix build github:edolstra/hello, Nix must inevitably somehow resolve this reference to a concrete revision. The concrete revision is a long hexadecimal string I cannot remember. Therefore I do see value in nix build to, when requested, just print the revision. Then, I can share its output (which now includes the resolved URL, which includes the hash) to my teammates, who can run the same build even if the revision that the default branch of github:edolstra/hello resolves to has changed in the meantime.
It's not a question of whether there is a possibility to somehow obtain a fully resolved flake URL, and that it can be provided as an argument to nix build, but a matter of convenience of the user experience with nix build.
| 20:58:37 |
Lorenz Leutgeb | * One nice property of flakes is that I can address them as github:edolstra/hello, that's something I can remember as a human. This reference changes over time and is not reproducible. Whenever I call nix build github:edolstra/hello, Nix must inevitably somehow resolve this reference to a concrete revision. The concrete revision contains a long hexadecimal string I cannot remember. Therefore I do see value in nix build to, when requested, just print the revision. Then, I can share its output (which now includes the resolved URL, which includes the hash) to my teammates, who can run the same build even if the revision that the default branch of github:edolstra/hello resolves to has changed in the meantime.
It's not a question of whether there is a possibility to somehow obtain a fully resolved flake URL, and that it can be provided as an argument to nix build, but a matter of convenience of the user experience with nix build.
| 20:58:59 |
Lorenz Leutgeb | * One nice property of flakes is that I can address them as github:edolstra/hello, that's something I can remember as a human. This reference changes over time and is not reproducible. Whenever I call nix build github:edolstra/hello, Nix must inevitably somehow resolve this reference to a concrete revision. The concrete revision contains a long hexadecimal string I cannot remember. Therefore I do see value in nix build to, when requested, just print the revision, i.e. the result of the resolution it must perform anyways. Then, I can share its output (which now includes the resolved URL, which includes the hash) to my teammates, who can run the same build even if the revision that the default branch of github:edolstra/hello resolves to has changed in the meantime.
It's not a question of whether there is a possibility to somehow obtain a fully resolved flake URL, and that it can be provided as an argument to nix build, but a matter of convenience of the user experience with nix build.
| 20:59:27 |
Lorenz Leutgeb | nix flake show does this by the way (as I have mentioned above), but there's no way for me to guarantee that the reference does not change in between invocations of nix build and nix flake show. That's why I am asking for a solution that only involves nix build. Or a convincing explanation for a better solution... | 21:03:38 |
pbsds | huh, you're right | 21:06:42 |
pbsds | there is no utility to expand github:nixos/nixpkgs#hello to e.g. github:NixOS/nixpkgs/7e63eed145566cca98158613f3700515b4009ce3#hello | 21:07:26 |
Lorenz Leutgeb | At least I couldn't find one... And if there would be one, I'd still prefer nix build to give me the expansion of the very thing I am building to avoid races (colleague pushing to Git in parallel, who knows...). | 21:08:24 |
Lorenz Leutgeb | * At least I couldn't find one... And if there would be one, I'd still prefer nix build to give me the expansion of the very thing I am building to avoid races (colleague pushing to Git host in parallel, who knows...). | 21:08:45 |
Lorenz Leutgeb | Also note that nix flake show --json does not print the resolved URL (which nix flake show does). I just filed an issue: https://github.com/NixOS/nix/issues/9230 | 21:09:44 |
Lorenz Leutgeb | If nix flake show --json would print the URL (analogously to nix flake show), then nix flake show --json FLAKE | jq -r 'keys[0]' would be the utility that resolves a flake to its precise URL. | 21:11:15 |
Lorenz Leutgeb | * If nix flake show --json would print the URL (analogously to nix flake show), then nix flake show --json FLAKE | jq -r 'keys' would be the utility that resolves a flake to its precise URL. | 21:11:43 |
Lorenz Leutgeb | * If nix flake show --json would print the URL (analogously to nix flake show), then nix flake show --json FLAKE | jq -r 'keys' would be the utility that resolves a flake to its precise URL. And then we would have to deal with the #hello part separately... | 21:12:14 |
| 25 Oct 2023 |
| @federicodschonborn:matrix.org changed their profile picture. | 00:12:36 |
| 26 Oct 2023 |
@lehmanator:gnulinux.club | What is the flakes way of going about installing packages from different nixpkgs branches?
I have been seeing stuff like this everywhere, but no equivalent method for flakes that doesn't break reproducibility:
unstable = import <nixos-unstable> {};
environment.systemPackages = [ unstable.myPackage ];
or
unstable = fetchTarball https://github.com/NixOS/nixpkgs/archive/nixos-unstable.tar.gz
I was thinking about making an overlay using flake-utils.lib.eachDefaultSystem to instantiate nixpkgs to be set as pkgs.unstable, but this feels wrong and I'm wondering if this will cause lots of cache misses & blow up my build times.
Is there a "best practices" way of going about this?
| 02:32:50 |
@petrichor:envs.net | In reply to @lehmanator:gnulinux.club
What is the flakes way of going about installing packages from different nixpkgs branches?
I have been seeing stuff like this everywhere, but no equivalent method for flakes that doesn't break reproducibility:
unstable = import <nixos-unstable> {};
environment.systemPackages = [ unstable.myPackage ];
or
unstable = fetchTarball https://github.com/NixOS/nixpkgs/archive/nixos-unstable.tar.gz
I was thinking about making an overlay using flake-utils.lib.eachDefaultSystem to instantiate nixpkgs to be set as pkgs.unstable, but this feels wrong and I'm wondering if this will cause lots of cache misses & blow up my build times.
Is there a "best practices" way of going about this?
you can include it as another input to your flake, like nixpkgs-unstable.url = "github:nixos/nixpkgs/nixos-unstable"; | 07:24:59 |
@lehmanator:gnulinux.club | In reply to @petrichor:envs.net you can include it as another input to your flake, like nixpkgs-unstable.url = "github:nixos/nixpkgs/nixos-unstable"; Right, but how should I make its packages accessible by the system / home-manager?
I know I can do something like:
| 19:12:25 |
@lehmanator:gnulinux.club | In reply to @petrichor:envs.net you can include it as another input to your flake, like nixpkgs-unstable.url = "github:nixos/nixpkgs/nixos-unstable"; * Right, but how should I make its packages accessible by the system / home-manager?
I know I can do something like:
| 19:12:32 |
@lehmanator:gnulinux.club | In reply to @petrichor:envs.net you can include it as another input to your flake, like nixpkgs-unstable.url = "github:nixos/nixpkgs/nixos-unstable"; * Right, but how should I make its packages accessible by the system / home-manager?
I know I can do something like:
nixpkgs.overlays = [
(final: prev: { pkgs.unstable = inputs.nixpkgs-unstable.legacyPackages.${prev.stdenv.system}; })
];
but I remember seeing one of the big maintainers saying that using a lot of overlays is discouraged and often causes slow builds, and suggested a better practice (which unfortunately I dont remember) for overriding / adding packages, but that was for one-off packages and not an entire instance of nixpkgs.
| 19:18:01 |
@lehmanator:gnulinux.club | This was specifically when using flakes, as using the channels mechanism breaks reproducibility. | 19:21:22 |
| 27 Oct 2023 |
| @federicodschonborn:matrix.org changed their profile picture. | 01:24:13 |
| 30 Oct 2023 |
Charles | In reply to @lehmanator:gnulinux.club
What is the flakes way of going about installing packages from different nixpkgs branches?
I have been seeing stuff like this everywhere, but no equivalent method for flakes that doesn't break reproducibility:
unstable = import <nixos-unstable> {};
environment.systemPackages = [ unstable.myPackage ];
or
unstable = fetchTarball https://github.com/NixOS/nixpkgs/archive/nixos-unstable.tar.gz
I was thinking about making an overlay using flake-utils.lib.eachDefaultSystem to instantiate nixpkgs to be set as pkgs.unstable, but this feels wrong and I'm wondering if this will cause lots of cache misses & blow up my build times.
Is there a "best practices" way of going about this?
when you do outputs = { self, ... }@inputs: ...; in your flake.nix, pass inputs to specialArgs, then you can use the flake inputs and outputs (via self) in your nixos modules. maybe home manager has something like specialArgs too | 04:13:21 |
Charles | In reply to @lehmanator:gnulinux.club
What is the flakes way of going about installing packages from different nixpkgs branches?
I have been seeing stuff like this everywhere, but no equivalent method for flakes that doesn't break reproducibility:
unstable = import <nixos-unstable> {};
environment.systemPackages = [ unstable.myPackage ];
or
unstable = fetchTarball https://github.com/NixOS/nixpkgs/archive/nixos-unstable.tar.gz
I was thinking about making an overlay using flake-utils.lib.eachDefaultSystem to instantiate nixpkgs to be set as pkgs.unstable, but this feels wrong and I'm wondering if this will cause lots of cache misses & blow up my build times.
Is there a "best practices" way of going about this?
* when you do outputs = { self, ... }@inputs: ...; in your flake.nix, pass inputs to specialArgs, then you can use the flake inputs and outputs (via self) in your nixos modules. maybe home manager has something like specialArgs too.
for example: https://or.computer.surgery/charles/servy-fleet/-/blob/3eae347d2cce33d1fed7371346b9d8b2aced891b/config/matrix-conduit/default.nix#L17
| 04:14:46 |
| @virtu:matrix.im joined the room. | 14:16:51 |