Homeless Dotfiles With Nix Wrappers

Links
1
12 Likes
2

I’m glad that wrappers are getting coverage! While not everything can be configured through wrappers, and good chunk of application can, and it’s pretty simple to do. Although I’m surprised wrapper-manager wasn’t even mentioned…

3 Likes
3

I cannot speak for the video, but wrapper-manager was an inspiration for building the wrappers. I focused more on a one module per package approach, because I want to upstream this paradigm into nixpkgs, so the amount of vendored code in home-manager, nix-darwin and other solutions can have a place in nixpkgs itself. And code can be more easily shared between those.

I will add wrapper-manager to the README in the coming days, after I solved some other issues I’m currently working on.

I would be interested in which software cannot be configured via wrappers? I think everything should work with a couple of workarounds. But I’m happy to learn where that can’t be the case :slight_smile:

3 Likes
4

Some software insists on files in specific locations, or is more of a “standard” than application config and can therefore not be moved. Examples include shell profiles or .ssh/config. The arch wiki has a pretty good list.

1 Like
5

for some easier usecases we could override HOME to a temporary directory and symlink the folders where the application saves/reads state from into there.

for harder usecases, something like proot could be used, although that is sadly not portable and slow, but could be a solution for linux only applications? I think there could be more “hacks” to make applications behave. We could even support preHooks to just create the config files before running the application.

1 Like
6

I think I’d quite like to use this for non-hacky purposes, but the moment we’re overriding HOME, let alone introducing kernel-level hacks, I think that’s going a little too far.

Mucking with the location of HOME will impact functionality, and while I’m fond of the idea behind proot, I don’t think I’d want to use it just to avoid hard coded paths unless it ends up in the mainline kernel somehow.

Even then, the issue with things like ~/.ssh/config is that they’re used by multiple applications in different contexts. It’s hard to track all of that down, let alone ensure that this same hack is applied to all of them.

I don’t think everything needs to be covered, in either case, I think this project is awesome enough if it gets us just 80% of the way there.

2 Likes
7

because I want to upstream this paradigm into nixpkgs, so the amount of vendored code in home-manager, nix-darwin and other solutions can have a place in nixpkgs itself. And code can be more easily shared between those.

Great! It would be nice to have some wrapper function in nixpkgs itself. When working on wrapper-manager and nix-maid, I also thought about having a “shared framework” for configuring an app, that would be agnostic about being implemented with wrappers or classical symlinks. But I’m not sure if this a path that would cause a lot of indirection and confusion. Though having this configuration framework directly in nixpkgs, along with some wrapper impl would makes things easier.

I would be interested in which software cannot be configured via wrappers?

I’m mainly referring to things like:

  • KDE (kconfig) and Gnome (gsettings). I don’t even see an easy way to start with plain wrappers. Maybe you can patch the whole thing to read the config files from a path, but then I wouldn’t want to reload my DE for a change.
  • Programs like firefox that hardcode ~/.firefox. Maybe can be done by using bwrap or similar on the target package, to mask in the target config into the filesystem.
  • Systemd-user units: this sounds like something out of scope for wrappers, but it what forces me to need some symlinking solution in my dotfiles, which otherwise would only use wrappers.

I’ve also had issues with git: some nix packages include git as a wrapped package into PATH (I think nixpkgs-review?), such that they pick their git instead of my wrapped git.