!SgYlXivkogarTVcnZO:nixos.org

Nix Flakes

902 Members
184 Servers

Load older messages


SenderMessageTime
1 Aug 2023
@ulrikstrid:matrix.org@ulrikstrid:matrix.orgIs 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@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:computer.surgeryCharles --override-input probably? 07:28:36
@avaq:matrix.orgAldwin joined the room.08:37:07
@avaq:matrix.orgAldwin

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
@avaq:matrix.orgAldwinRight, 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:nurupo.plmewp
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
@avaq:matrix.orgAldwinThanks! Yeah I figured that once that problem presents itself I'll just add a second nixpkgs input.16:39:26
@avaq:matrix.orgAldwininputs.nixpkgsWhereCowsayDoesThatWeirdThingINeedForServiceFoo16:40:20
@avaq:matrix.orgAldwinSo I did go for a single flake for the whole repo, it seems very natural16:42:38
@yoav-lavi:matrix.orgYoav Lavi joined the room.18:05:22
@symphonic-logic:matrix.orgsymphonic-logic joined the room.18:25:04
2 Aug 2023
@adam:valkor.net@adam:valkor.net left the room.23:42:19
3 Aug 2023
@silvio:booq.org@silvio:booq.org left the room.16:19:58
@esperlily:matrix.orgEsperLily [she/her] joined the room.21:15:23
4 Aug 2023
@ThorHop:matrix.org@ThorHop:matrix.org joined the room.12:35:55
@lyle:menteeth.usIslandUsurper left the room.14:12:42
5 Aug 2023
@ThorHop:matrix.org@ThorHop:matrix.orgSo how do you check for updates on a flake based system? Also, how do you update?02:25:00
@2xsaiko:tchncs.de@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@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:lodere.esfpletz joined the room.11:59:54
@eigrp:matrix.orgeric changed their display name from eigrp to eric.21:14:01
@eigrp:matrix.orgeric set a profile picture.21:14:05
6 Aug 2023
@ronnypfannschmidt:matrix.org@ronnypfannschmidt:matrix.orgis 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:hrnz.liulliself.outPath17:39:30
@sss:matrix.dark-alexandr.netsss joined the room.19:24:28
7 Aug 2023
@ncfavier:matrix.orgnf changed their profile picture.09:41:26
8 Aug 2023
@lxsameer:matrix.orglxsameer joined the room.15:46:04
@orowith2os:fedora.imOro (any/all) joined the room.20:26:26
9 Aug 2023
@jeff:ocjtech.usJeff changed their profile picture.03:10:58

Show newer messages


Back to Room ListRoom Version: 6