I think they might have read this thread, where the Discourse OP is using Home Manager to declare podman containers because the NixOS module just doesn't support doing that. And flakes ended up in the question because a lot of other examples online just assume the reader is using flakes.
I'm not a podman user so I'm not sure how much work it would be to not use Home Manager here, it feels like it shouldn't be much more annoying than what the discourse OP is already doing, but I haven't tried.
If you just want pinning you can also use npins, and it doesn't do any of the annoying other things Flakes do like copying the entire repository to the Nix store or failing to import unstaged or gitignored files.
The NixOS community has a lot of cargo culting going on, probably because it's not super accessible. Using Flakes and Home Manager for absolutely everything is a part of that in my opinion. I ended up going back and forth on both of them, my current opinion is that Home Manager makes sense (if you have a use case for it) but Flakes don't.
If you really need to import a flake-only project from a non-Flake config you can use builtins.getFlake. Personally if a project makes this required by inlining everything in a flake.nix I would consider that a sign of shoddy programming and it makes me reconsider using it, but it is possible.
If you're talking about using snippets of what other people have in their configs, then most of them should work perfectly fine. You may have to replace an inputs.whatever.nixosModules.default with a fetchTarball or an equivalent reference to an npins file but that's a pretty minor change.
For Home Manager such a translation doesn't exist because Home Manager does a lot of different things, and even when HM reimplements something that's already in NixOS (like HM dconf vs NixOS services.dconf) it usually doesn't quite act the same way, if only because most programs treat package, system and user configuration differently.
They have their reason for being, flakes help with reproducibility by pinning the versions, whereas home manager helps with running stuff as non-root and in non-NixOS systems.
Your flake.nix can just have a default output that points to your configuration.nix and you're done. That's how my flake started.
I'm not sure what you want to achieve... do you want NixOS running in podman containers as a service? Do you want to have some kind of package that starts up podman with nix packages in it?
Could you provide your usecase(s)? "As a X I want to Y". "As a X when I do Y I expect Z to happen".
It's just confusing to see flakes and home manager mentioned and some "backported" podman output to be desired. Individually those words make sense but together I'm lost.
What makes a flake config a flake config is simply the flake.nix entry point. So, technically if you read that file to see what file it loads for the nixosConfiguration you want to "port", you should be able to just go directly from that file and bypass the flake.nix.
For the longest time, my own flake simply forwarded to my configuration.nix.
However, depending on your needs of course, but using flakes even at a basic level can be very useful and I'd 100% encourage doing a basic setup for someone starting out. The main feature here is being able to lock your dependencies (including nixpkgs) to a specific commit, which means you will always get the same resulting setup (not depending on when you installed it, like it does without flakes). But, you know better than me the requirements of your own setup :)
Thank you for the caution!
You should be able to rebuild offline if the minimal change set is self contained enough, as in purely local. Did you update any other inputs? I guess you could be missing some kind of extra TLS or CA store dependency for adding custom CAs, but that doesn't seem likely for regular NixOS install. I use flakes instead of channels, so I wouldn't know what else may be blocked you. A stdout log may showcase your error more clearly.
The problem is that I cannot successfully rebuild because of the SSL certificate errors. Is there any way to bypass the SSL verification?
I think you may need a successful switch to actually apply the addition of the proxy CA to your root CA store before attempting any other changes that could require reaching out across the network. At least that was the order of operations I had to follow to remove an offline remote cache before attempting any package updates.
Be careful, backup regularly.
That sounds clever. I like it.
Never used BTRFS but notes a good time to learn!
If you go with the btrfs option, you could change the wipe script to copy all files to a specific location and manually inspect that after reboot.
This is fabulous - exactly what I was hoping for!
I feel like I want a easy to either detect live, or diff before shutdown, changes and file creation that I might want to add to my impermanent configs.
THAT'S the word I was looking for!
Thank you.
Now I can hit the wiki. https://nixos.wiki/wiki/Impermanence
I did more or less your idea with kiosk mode. Everything which is not explicitly defined by nix is on tmpfs in my setup. But I don't play games on this machine, so I can't say anything to this.
I've got the idea from "erase your darlings": https://grahamc.com/blog/erase-your-darlings/
The same thing with btrfs: https://hanckmann.com/posts/20230104-nixos-and-erasing-my-darlings/
The whole idea is about impermanence: https://github.com/nix-community/impermanence
I've been happily using impermanence for well over a year now, with BTRFS under my persistent volume on most hosts (and tmpfs for /, because that was easier, and I don't need the safety of having snapshots of my impermanent stuff), and it gets me that great freshly installed system feeling on every boot, and incredibly convenient backups.
Can recommend.
Check out https://grahamc.com/blog/erase-your-darlings/ ; it uses zfs, but should be easy enough to adapt to your use-case.
Cool, looks like garnix is fast. I wanted to use it, but home page and docs are hard to parse. Too big fonts, required scrolling and bad docs organization. Why can't all projects just use material for mkdocs?
I don't know much about btrfs, but couldn't you just keep the same mountpoints?
I followed these instructions to do a "lustrate" install on top of my old Debian install. At the end, I reallly scrutinized the autogenerated hardware-configuration.nix, decided it was close enough to my old /etc/fstab, and bit the bullet with sudo reboot. It worked except for a small hiccup that I can't even remember the details of now.
https://nixos.org/manual/nixos/stable/#sec-installing-from-other-distro
Nix has one great idea and one terrible idea. Until at least the configuration language is redesigned by someone with good taste (and sanity), I'm not touching it. The amount of effort it takes to get back into the nix headspace in order to maintain anything is just not worth it. Docker and Podman are trivial by comparison, and the benefits of Nix do not justify the headaches. I Nix on a personal server for a few months, but migrated back to Podman after I found myself spending way too much time trying to find documentation and make sense of crackhead JSON.
In my work I get to use Conan which kind of implements some of the same ideas as Nix/Guix. It's designed for a different use case, but the benefits are similar and I love using it. It also has a learning curve, but Python is a real programming language at least. Guix may have the right idea too, but my experience with FSF projects is that they choose ideology over practicality every time, so I'm not eager to dive into it.
Guix is fine. Some people complain about the "speed" of it and some people who want to game say it's a no go. I haven't played around much with it myself so I can't speak on it first hand so YMMV.