| 1 Aug 2023 |
@ulrikstrid:matrix.org | Is it possible to do `nix build GitHub:...` and somehow set one of the inputs to a different version? Might be a weird usecase but we're maintaining a overlay and each to check if we're breaking a couple of our users | 06:45:18 |
@ulrikstrid:matrix.org | * Is it possible to do `nix build GitHub:...` and somehow set one of the inputs to a different version? Might be a weird usecase but we're maintaining a overlay and want to check if we're breaking a couple of our users | 06:45:39 |
Charles | --override-input probably? | 07:28:36 |
| Aldwin joined the room. | 08:37:07 |
Aldwin | Hi! I've been using NixOS for some 6 years, and I feel pretty comfortable with it. But I've never made the leap to Flakes, and know very little about them. But I want to learn more.
I have large repository of configuration modules that I use to compose nixoses for several personal machines. I've also used nix at work to deploy several web services. For the web services, I'd typically create:
- A
package.nix that defines how my source code is built into an executable;
- a
service.nix that defines the systemd units and whatever config is needed to run it in a machine;
- a
default.nix (containing only callPackage ./package.nix {} or something) for local builds and shells; and
- a
deployment.nix (or production.nix / acceptance.nix) that has the environment and hardware specific things.
I deploy by simply using nixos-rebuild deployment.nix --target-host .... When I have multiple web-services in a single repository, the whole structure just moves into the corresponding sub-directories, and I call nixos-rebuild on each of 'em.
In the deployment pipeline I pin nixpkgs to a specific hash, but that doesn't guarantee that local builds and shells use the same version of nixpkgs and whatnot. Today, I'm looking into migrating one of these projects to Flakes, mainly to improve reproducibility.
I'm looking for some general guidelines as to how to go about this.
- Should I be creating multiple flakes? Like, one for the package and one for the service? Or should I combine everything into a single flake?
- In the monorepo case, should I have a single flake at the root that just defines multiple build outputs? I can imagine that that makes managing locks easier? Or should I stick with a flake per package / target host?
- How do I reuse packages? Do I still create derivations that I can import with
callPackage or does Flakes replace it?
| 09:00:46 |
Aldwin | Right, so I kept most of what I had the same, but I added a flake.nix to my project root that imports all the various packages and systems within the context of a pinned-down nixpkgs input. This seems to be working for me. | 11:35:48 |
mewp | In reply to @avaq:matrix.org
Hi! I've been using NixOS for some 6 years, and I feel pretty comfortable with it. But I've never made the leap to Flakes, and know very little about them. But I want to learn more.
I have large repository of configuration modules that I use to compose nixoses for several personal machines. I've also used nix at work to deploy several web services. For the web services, I'd typically create:
- A
package.nix that defines how my source code is built into an executable;
- a
service.nix that defines the systemd units and whatever config is needed to run it in a machine;
- a
default.nix (containing only callPackage ./package.nix {} or something) for local builds and shells; and
- a
deployment.nix (or production.nix / acceptance.nix) that has the environment and hardware specific things.
I deploy by simply using nixos-rebuild deployment.nix --target-host .... When I have multiple web-services in a single repository, the whole structure just moves into the corresponding sub-directories, and I call nixos-rebuild on each of 'em.
In the deployment pipeline I pin nixpkgs to a specific hash, but that doesn't guarantee that local builds and shells use the same version of nixpkgs and whatnot. Today, I'm looking into migrating one of these projects to Flakes, mainly to improve reproducibility.
I'm looking for some general guidelines as to how to go about this.
- Should I be creating multiple flakes? Like, one for the package and one for the service? Or should I combine everything into a single flake?
- In the monorepo case, should I have a single flake at the root that just defines multiple build outputs? I can imagine that that makes managing locks easier? Or should I stick with a flake per package / target host?
- How do I reuse packages? Do I still create derivations that I can import with
callPackage or does Flakes replace it?
nixpkgs is a single flake. I'd create a single flake for the whole repo. There's a downside to that, however: all packages in that flake will likely depend on one nixpkgs version. updating the lock will update nixpkgs for all these packages. on the other hand, it's possible to have multiple nixpkgs in a flake, so it isn't a big problem | 16:09:32 |
Aldwin | Thanks! Yeah I figured that once that problem presents itself I'll just add a second nixpkgs input. | 16:39:26 |
Aldwin | inputs.nixpkgsWhereCowsayDoesThatWeirdThingINeedForServiceFoo | 16:40:20 |
Aldwin | So I did go for a single flake for the whole repo, it seems very natural | 16:42:38 |
| Yoav Lavi joined the room. | 18:05:22 |
| symphonic-logic joined the room. | 18:25:04 |
| 2 Aug 2023 |
| @adam:valkor.net left the room. | 23:42:19 |
| 3 Aug 2023 |
| @silvio:booq.org left the room. | 16:19:58 |
| EsperLily [she/her] joined the room. | 21:15:23 |
| 4 Aug 2023 |
| @ThorHop:matrix.org joined the room. | 12:35:55 |
| IslandUsurper left the room. | 14:12:42 |
| 5 Aug 2023 |
@ThorHop:matrix.org | So how do you check for updates on a flake based system? Also, how do you update? | 02:25:00 |
@2xsaiko:tchncs.de | hopland: update: nix flake update check for updates, run it after nix flake update but before building the system: nix store diff-closures --derivation /run/current-system .#nixosConfiguration.$HOST.config.system.build.toplevel (this is at least one way) | 02:55:46 |
@2xsaiko:tchncs.de | * hopland: update: nix flake update check for updates, run it after nix flake update but before building the system: nix store diff-closures --derivation /run/current-system .#nixosConfigurations.$HOST.config.system.build.toplevel (this is at least one way) | 02:55:58 |
| fpletz joined the room. | 11:59:54 |
| eric changed their display name from eigrp to eric. | 21:14:01 |
| eric set a profile picture. | 21:14:05 |
| 6 Aug 2023 |
@ronnypfannschmidt:matrix.org | is there any easy way to have a flake refer to its incoming location and/or its store copy in a safe manner - im on a host system with fedora that shares a multi-user nix store with my nixos root and i want to automate a nixos-enter jump that invokes nixos-rebuild boot with the flake (so i can install system updates on my nix from my fedora)
| 16:29:55 |
ulli | self.outPath | 17:39:30 |
| sss joined the room. | 19:24:28 |
| 7 Aug 2023 |
| nf changed their profile picture. | 09:41:26 |
| 8 Aug 2023 |
| lxsameer joined the room. | 15:46:04 |
| Oro (any/all) joined the room. | 20:26:26 |
| 9 Aug 2023 |
| Jeff changed their profile picture. | 03:10:58 |