Approach For Wrapping Bash?

[ameertaweel]

I would like to set per-user environment variables without using Home Manager. I thought that wrapping Bash can work. The idea is:

1. Add my environment variables to Bash by wrapping it.
2. Set users.users.<name>.shell to wrapped Bash.

In the second step, Nix complained that wrapped Bash "is not a shell package". After reading Nixpkgs code I realized it's looking for pkg.shellPath. So I used passthru.shellPath = config.package.shellPath (which is /bin/bash). Now Nix wasn't complaining. However, it was still using normal Bash as the shell, none of my environment variables where set.

I would appreciate it if someone points me towards the issue here. I don't understand why Nix is completely ignoring users.users.<name>.shell, even though it works when I set it to pkgs.fish or something. There must be something wrong with my wrapped Bash.

[BirdeeHub]

So, if it is working when you use a fish derivation, that should rule out something setting lib.mkForce and winning, or some weird interaction with users.defaultUserShell (or whatever it is)?

So, that is useful information.

https://github.com/NixOS/nixpkgs/blob/23d72dabcb3b12469f57b37170fcbc1789bd7457/nixos/lib/utils.nix#L148-L156

^ The logic they use to select it is strange, I am unsure why they select it from /run/current-system/sw like that.

Try doing users.users.<name>.shell = "${pkgs.urbash}/bin/bash"; ?

Not really sure why it would not work still, but that may be part of it?

I tested the wrapped bash on its own, just calling it in a shell, and the values from env option do seem to propagate when its on its own? So its not a bash refusing outside vars thing?

Did you used to use home manager and now you don't? If the above doesn't help, what are the chances of old files still being there?

---

Also, you will want to use wrapperImplementation = "binary"; otherwise you won't be able to use it in shebangs on mac without the whole #!/usr/bin/env bash thing

[ameertaweel]

Indeed when I tested the wrapped Bash on it's own the values from env propagated properly. Only when I used it with users.users.<name>.shell did I face this issue.

And I was testing this using nixos-rebuild build-vm that doesn't have home-manager, which rules out any home-manager leftovers.

But your suggestion of trying users.users.<name>.shell = "${pkgs.urbash}/bin/bash" totally worked!

When I login, wrapped Bash starts, with all env vars set properly.

But then if I run Bash by typing bash, it starts unwrapped Bash.

However, after adding wrapped Bash to users.users.<name>.packages, running bash starts wrapped Bash as well.

I'm not sure if this setup will lead to undesired behavior, but I will experiment with it. It would be amazing if it works as it's very clean.

[BirdeeHub]

I mean, that would work, but then you wouldn't have the things nixos added probably? I am assuming that is why that is there?

Also, you can try it with yours no? Just setting users.users.<name>.shell = "${wrappedzsh}/bin/zsh";?

His wrapper is just setting ZDOTDIR like yours is. The bug was, if you do that, things you add via extraPackages will get removed.

[zenoli]

@zenoli if you get a chance could you try adding the -d flag to your wrapper, while also not having programs.zsh enabled. I think this should stop /etc/profile from being sourced and /etc/.zshenv won't exist.

Yes, this would work. But I think moving path modifications out of the wrapper and inside zshenv is the better solution for now.

The only downside to installing the wrapper via users.users.<name>.shell = lib.getExe config.wrappers.zsh.wrapper; is, that I need to logout (even restart) for changes to apply. Hence I also set programs.kitty.settings.shell = lib.getExe config.wrappers.zsh.wrapper; in my hm-config (this alone would already satisfy 95% of my uscases. setting it as the system wide default shell is only for cases where I want to ssh into my computer). It's not perfect but good enough for me right now.

[BirdeeHub]

@zenoli #347 ?

Any design notes?

I don't want to get into the mess of plugins and all that (at least not yet without more investigation), it is pretty easy to make an option that sources stuff, and you could drop your integrations thing right into the config.zshrc.content or whatever (also placeholders work in that)

What about the wrapperVariants thing in the module.nix where it doesnt mirror but can be used to wrap other things into it? (similar to what I did with them in the neovim module) Too messy? Cool? Should I disable wrapperVariants for it entirely?

[zenoli]

I'm at work rn and will only have time to review it in like 10 hours (I am glad to do so if you can wait :-))
If I read it correctly, your PR is mostly a finalization of @FluxZA 's vision (a very unopinionated wrapper that abstracts away some complex boilerplate of initializing global RC stuff and then provides the user complete freedom to shape their .zshenv, .zshrc, .zprofile etc?

If yes, then I think this is the way to go.
What I am fiddling around is a completely different appraoch: It is very opinionated in the sense that I provide nix options for things that I think everyone mostly sets up the same anyway.

In case I ever get to a point where I think my zsh wrapper is useful enough to be shared, I thought about either...

1. ... integrating it into the official zsh-wrapper from this repo in a "completely opt-in" way (people can still integrate stuff directly into their wrapped .zshrc) or...
2. ... expose it as a standalone wrapper (like nixcats/nixvim/nvf).

[BirdeeHub]

Yes. Very unopinionated exactly.

Although, I'm not necessarily opposed to adding more, especially if it is something that improves compat with nixos or home-manager.

You could initially publish it as a wrapper module in its own flake which imports this one currently in the PR (once it is live obv), and then sets the options for the ZDOTDIR files with the content of what your options do.

Then, they could still append to those by setting the values (they are lib.types.lines) and also they could use your options as well. Gives you quite a bit for free in that department, as there is another layer of options under yours.

There also will eventually be an easy way to generate docs for such a 3rd party wrapper module too.

Also, if you make your top level module for zsh of _class = "zsh"; It would refuse any _class = "neovim"; modules. So, that is kinda fun and we may have a use for _class one day. But users can still set it themselves anyway, so, its fine for now. What it does show though, is that _class = "wrapper"; is likely the wrong approach.

In the long term, we currently have a modules and a helper modules, we could maybe add an extension modules/collection of stuff thing, with something like that in it? And maybe also some neovim or xplr or whatever extras too? Would be cool if someone made a collection of neovim language modules too, and that would be the place to host them one day.

But thats in the long term, when we have more people that can merge to this thing XD (which probably won't be happening until after it is in nix-community, which will be happening after I finish figuring out the docgen and maybe services?)

But in the meantime, you could totally publish it as its own wrapper module which extends this one and it would be useful in that endeavor.

Modules deduplicate by path, so don't worry much about how that will feel for users to import it into their already existing zsh module too.

The one in the PR is already kinda a lot of logic, hence the hesitation to cover more there, but you could take that base design as far as you wanted.

It sources in order (for each one individually of course):

• the file from the specified config.zdotdir

• Then the path from the file option

• then the content from the file option (placeholders work here)

And yes, I will be waiting at least that long, as am not sure of a few things still, and I need @FluxZA to weigh in on if they want to be added as one of the maintainers still or not since I changed it (they did good work chasing down the details on what to source from nixpkgs, I appreciate it)