when I first started using NixOS I was like you. I refused to use flakes and the home manager cause it just didn’t make sense to me. Then I borked my system royally and had to reinstall. just going off the configuration.nix alone was…it was rough. possible but rough. So I decided to use flake, home manager, along with my configuration and then suddenly NixOS just clicked for me, I finally made sense.

using all 3 just makes your system easier to manage. For example say you use a WM and you want to keep your WM (like niri or hyprland or sway or i3 or whatever) config reproducible just like the rest of your system. Sure you can throw your entire config into the home manager OR you can simply have the home manager literally manage said config. Keep your config files in your “nixos-configs” directory along with your home, flake, and configuration.nix and repo all that, boom it’s backed up and easy to reproduce if something goes wrong or you want to move your ENTIRE system to another computer. I do this for Niri, KDE, Yazi, Aerc, DOOM Emacs, Nvim, whatever I have a config for. So say I royally mess up a config for one of those programs or WMs just like my NixOS I can go back to a previous generation of one of them very easily thanks to my home manager.

Flakes are also good in case you want to use something that hasn’t been packaged on NixOS. Say like some awesome TUI or application someone recently made you can input the git repo into your flake and then “install” it via your home manager. makes things easy.

It also helps to understand and manage if you sort what each thing does. For me I use my home.nix to list packages that I directly interact with. So stuff like Qutebrowser, floorp, steam, OBS, Krita, etc, etc are all in my home manager. stuff that’s more backend/system dependent like git, libnotify, fzf, etc are in my configuration.nix i.e. the config of my OS while the home.nix is just like a package list and config files of things I’m more likely to interact with on a daily basis. It’s easier to manage when things are separate like that.

I keep all of this stuff in its own directory that is a git repo. so before I rebuild I stage it all. then rebuild. if it’s good commit it all, push it to my forgejo, boom instantly backed up. something goes wrong then I can either roll back a generation or clone the repo and rebuild from that.

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.

God, I wish I could just do like a live coding session with a group to explain what I know and like and how to translate that into flakes and hm. Lots of good info and suggestions from everyone, but I feel I could explain myself better with my system in front of me. I get the flakes concept of locking a program to a particular version. I like that idea, but I also think I’m still in a stage of building out my system, discovering which packages I want. And I understand home manager is for handling my home folder and config within nix.

I can’t place it, but for some reason I don’t mind my config files living in .config, and keeping my system (for now) up to date and running the latest version of most software. That being said I of course see the value in both of these in the long term, especially as I work to build out a config I can install on all my systems and automatically toggles the correct modules based on device and user. I want that, but my repeat failure to get the flakes I want working, working, tells me I need to learn more base nix before I tackle that.

In fact I could tell I learned a lot when I had to figure out how to remove flakes and hm when I kind of got them working. While I had moved my config into home manager, I also broke a bunch of other things, rendering enough of my desktop environment non-functional (audio mostly lol), that I needed to do something. The solution I knew I could pull off was completely rewriting my config as a sort of in between of my single file Hyprland based config, to a directory of files and niri. Learning to properly import other files, learning about needing to include default.nix and how I can toggle which files are imported very easily with comments. The broader nix ecosystem started to make more sense.

I finally got good about using git, I made a folder structure that makes a lot of sense to me as far as parts of my config that are interoperable or machine specific. It’s clicking. I know the next step from that is probably flakes and hm, but again, the last time I tried to add those to my config, I broke way more than I fixed.

I feel just dumb enough with this that I’m not sure I’m comfortable sharing my config publicly yet. For example I haven’t implemented a secrets setup, so things like my syncthing IDs are in my config still.

As far as clearer goals. I’d like a config I can distribute across 3 machines (for now).

• A desktop running niri, and kind of for fun as much other rust based software as possible (iron bar, helix, etc.). I know there will have to be exceptions, but it’s been fun engaging with a lot of recent work using rust.
• A home server/nas/router using Podman for containers like Tailscale/wireguard, Jellyfin, audiobookshelf and such. If this can also handle my pihole/local dns and firewall that would be awesome, but I also have a RespberryPi I can dedicate to those.
• A living room PC that boots straight to steam big picture, and has all the emulator platforms I could ask for.

There’s many more thoughts prancing around in my head, but I don’t know how to prompt them.

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 :)

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.

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.