nix show-config 
accept-flake-config = false
access-tokens = 
allow-dirty = true
allow-import-from-derivation = true
allow-new-privileges = false
allow-symlinked-store = false
allow-unsafe-native-code-during-evaluation = false
allowed-impure-host-deps = 
allowed-uris = 
allowed-users = *
auto-allocate-uids = false
auto-optimise-store = false
bash-prompt = 
bash-prompt-prefix = 
bash-prompt-suffix = 
build-hook = /nix/store/q6r9kwmidiy6wx1w1nf3ff0q40sfq4dg-nix-2.15.1/bin/nix __build-remote
build-poll-interval = 5
build-users-group = 
builders = @/etc/nix/machines
builders-use-substitutes = false
commit-lockfile-summary = 
compress-build-log = true
connect-timeout = 0
cores = 20
diff-hook = 
download-attempts = 5
download-speed = 0
eval-cache = true
experimental-features = flakes nix-command
extra-platforms = ["qemu-user"]
fallback = false
filter-syscalls = true
flake-registry = https://channels.nixos.org/flake-registry.json
fsync-metadata = true
gc-reserved-space = 8388608
hashed-mirrors = 
http-connections = 25
http2 = true
id-count = 8388608
ignore-try = false
ignored-acls = security.csm security.selinux system.nfs4_acl
impersonate-linux-26 = false
keep-build-log = true
keep-derivations = true
keep-env-derivations = false
keep-failed = false
keep-going = false
keep-outputs = false
log-lines = 10
max-build-log-size = 0
max-free = 18446744073709551615
max-jobs = 1
max-silent-time = 0
min-free = 0
min-free-check-interval = 5
nar-buffer-size = 33554432
narinfo-cache-negative-ttl = 3600
narinfo-cache-positive-ttl = 2592000
netrc-file = /etc/nix/netrc
nix-path = /home/fabi/.nix-defexpr/channels
plugin-files = 
post-build-hook = 
pre-build-hook = 
preallocate-contents = false
print-missing = true
pure-eval = true
require-sigs = true
restrict-eval = false
run-diff-hook = false
sandbox = true
sandbox-build-dir = /build
sandbox-dev-shm-size = 50%
sandbox-fallback = true
sandbox-paths = /bin/sh=/nix/store/q9iqbf8fg6wa50qka0zx82lxdi309s7k-busybox-static-x86_64-unknown-linux-musl-1.36.1/bin/busybox
secret-key-files = 
show-trace = false
ssl-cert-file = /etc/ssl/certs/ca-certificates.crt
stalled-download-timeout = 300
start-id = 872415232
store = auto
substitute = true
substituters = https://cache.nixos.org/
sync-before-registering = false
system = x86_64-linux
system-features = benchmark big-parallel kvm nixos-test uid-range
tarball-ttl = 3600
timeout = 0
trace-function-calls = false
trace-verbose = false
trusted-public-keys = cache.nixos.org-1:6NCHdD59X431o0gWypbMrAURkbJ16ZPMQFGspcDShjY=
trusted-substituters = https://cache.nixos.org
trusted-users = root
use-case-hack = false
use-cgroups = false
use-registries = true
use-sqlite-wal = true
use-xdg-base-directories = false
user-agent-suffix = 
warn-dirty = true

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?

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?