Unnecessary to create ~/.zshenv when dotDir is set

[Th3Whit3Wolf]

Issue description

Home manager creates a ~/.zshenv unnecessarily, cluttering the home directory.

https://github.com/nix-community/home-manager/blob/a759143ae130e68b8c0ce867c28b3e006f9920e0/modules/programs/zsh.nix#L407-L417

it would be nice to either have an option to not create this file or instead make this global like this.

environment.etc."zsh/zshenv" = {
  text = ''
    ZDOTDIR=${zdotdir}
  '';
};

[berbiche]

Home Manager only changes files in a user's home directory. Changing things globally is outside the scope of HM and will probably never be implemented.

Technically, you can probably make a dummy configuration where the homeDirectory is /etc, use an empty configuration and only write files using home.files (e.g. home.files."zsh/zshenv".text = "ZDOTDIR=something").

[Th3Whit3Wolf]

Home Manager only changes files in a user's home directory. Changing things globally is outside the scope of HM and will probably never be implemented.

That's what I figured, I put the snippet their really for anyone who wasn't familiar with the solution.

Technically, you can probably make a dummy configuration where the homeDirectory is /etc, use an empty configuration and only write files using home.files (e.g. home.files."zsh/zshenv".text = "ZDOTDIR=something").

I think I'd prefer be able to set a boolean to not create ~/.zshenv

[Th3Whit3Wolf]

I think this maybe possible using systemd.user.sessionVariables

[fricklerhandwerk]

Home manager creates a ~/.zshenv unnecessarily, cluttering the home directory.

It only happens if zsh itself is enabled, and even then only if you

• add oh-my-zsh

https://github.com/nix-community/home-manager/blob/a759143ae130e68b8c0ce867c28b3e006f9920e0/modules/programs/zsh.nix#L399-L404

• have extra lines to add to the environment

https://github.com/nix-community/home-manager/blob/a759143ae130e68b8c0ce867c28b3e006f9920e0/modules/programs/zsh.nix#L382-L385

• relocate the config directory

https://github.com/nix-community/home-manager/blob/a759143ae130e68b8c0ce867c28b3e006f9920e0/modules/programs/zsh.nix#L406-L418

Running rg zshenv, rg oh-my-zsh, rg envExtra on the repo does not show any other relevant results.

Did you enable any of the above?

[Th3Whit3Wolf]

@fricklerhandwerk yes I use an XDG Compliant directory for my configs. I have renamed the issue to reflect that.

[uvNikita]

I might be missing something here, but as far as I remember ~/.zshenv is necessary to set ZDOTDIR environment variable in the first place, otherwise how zsh will know where config files are located?

[Th3Whit3Wolf]

@uvNikita when I get some free time I'm going to try to set it with systemd user environment variables. I could be wrong but I believe they are set by logind and before zsh

[teto]

@uvNikita wouldn't it be possible via sessionVariables ?

[uvNikita]

@teto I don't think so, because, unless I'm missing something, those variables are set via zshrc:

https://github.com/nix-community/home-manager/blob/f9e45390deced72bc7cc0b75d3a922aa10a33e08/modules/programs/zsh.nix#L480

[Th3Whit3Wolf]

@teto @uvNikita hm-sessiom-vars.sh contains variables set by home. sessionVariablesExtra I think systemd.user.sessionVariables might work

[uvNikita]

@Th3Whit3Wolf I haven't tried it, but seems like environment.d (which is generated from systemd.user.sessionVariables) is used to set environment for services only(?):

Configuration files in the environment.d/ directories contain lists of environment variable assignments for services started by the systemd user instance.

https://www.freedesktop.org/software/systemd/man/environment.d.html#Description

So it might work for graphical sessions if they would be started as systemd services, but I don't think it would work for something like ssh sessions.

[Th3Whit3Wolf]

I haven't tried it either. But I know it is the recommended way to set user environment variables under wayland.

gnome recommends it here

[rycee]

I think it may be worth exploring use of environment.d for possible introduction in the next release cycle but it has to be done with care, we'd want to avoid problems like in https://github.com/nix-community/home-manager/issues/1999.

Oh, and ideally it should be considered in NixOS as well so that we avoid having an impedance mismatch between NixOS and HM.

[fricklerhandwerk]

Yes, and let's not forget that systemd is not the only mechanism out there. We have a substantial user base on Darwin, for which #1999 also applies.

[stale[bot]]

Thank you for your contribution! I marked this issue as stale due to inactivity. If this remains inactive for another 7 days, I will close this issue. Please read the relevant sections below before commenting.

If you are the original author of the issue

• If this is resolved, please consider closing it so that the maintainers know not to focus on this.
• If this might still be an issue, but you are not interested in promoting its resolution, please consider closing it while encouraging others to take over and reopen an issue if they care enough.
• If you know how to solve the issue, please consider submitting a Pull Request that addresses this issue.

If you are not the original author of the issue

• If you are also experiencing this issue, please add details of your situation to help with the debugging process.
• If you know how to solve the issue, please consider submitting a Pull Request that addresses this issue.

Memorandum on closing issues

If you have nothing of substance to add, please refrain from commenting and allow the bot close the issue. Also, don't be afraid to manually close an issue, even if it holds valuable information.

Closed issues stay in the system for people to search, read, cross-reference, or even reopen--nothing is lost! Closing obsolete issues is an important way to help maintainers focus their time and effort.

[utkarshgupta137]

Not completed

[stale[bot]]

Thank you for your contribution! I marked this issue as stale due to inactivity. Please be considerate of people watching this issue and receiving notifications before commenting 'I have this issue too'. We welcome additional information that will help resolve this issue. Please read the relevant sections below before commenting.

If you are the original author of the issue

• If this is resolved, please consider closing it so that the maintainers know not to focus on this.
• If this might still be an issue, but you are not interested in promoting its resolution, please consider closing it while encouraging others to take over and reopen an issue if they care enough.
• If you know how to solve the issue, please consider submitting a Pull Request that addresses this issue.

If you are not the original author of the issue

• If you are also experiencing this issue, please add details of your situation to help with the debugging process.
• If you know how to solve the issue, please consider submitting a Pull Request that addresses this issue.

Memorandum on closing issues

Don't be afraid to manually close an issue, even if it holds valuable information. Closed issues stay in the system for people to search, read, cross-reference, or even reopen – nothing is lost! Closing obsolete issues is an important way to help maintainers focus their time and effort.

[Theaninova]

For anyone interested, you can work around this right now (in my case I have hm as a NixOS module): clean-zsh.nix

{ config, ... }:
let
  xdgConfig = config.home-manager.users.YOUR_USERNAME.xdg
in
{
  environment.etc."zshenv".text = ''
    source ${xdgConfig.configHome}/zsh/.zshenv
  '';
  home-manager.users.YOUR_USERNAME = {
    home.file.".zshenv".enable = false;
    zsh = {
      dotDir = ".config/zsh";
      history.path = "${xdgConfig.stateHome}/zsh/history";
    };
  };
}

configuration.nix

{ ... }:
{
  imports = [ ./clean-zsh.nix ];
}

I got a more elaborate version of this here

[stale[bot]]

Thank you for your contribution! I marked this issue as stale due to inactivity. Please be considerate of people watching this issue and receiving notifications before commenting 'I have this issue too'. We welcome additional information that will help resolve this issue. Please read the relevant sections below before commenting.

If you are the original author of the issue

• If this is resolved, please consider closing it so that the maintainers know not to focus on this.
• If this might still be an issue, but you are not interested in promoting its resolution, please consider closing it while encouraging others to take over and reopen an issue if they care enough.
• If you know how to solve the issue, please consider submitting a Pull Request that addresses this issue.

If you are not the original author of the issue

• If you are also experiencing this issue, please add details of your situation to help with the debugging process.
• If you know how to solve the issue, please consider submitting a Pull Request that addresses this issue.

Memorandum on closing issues

Don't be afraid to manually close an issue, even if it holds valuable information. Closed issues stay in the system for people to search, read, cross-reference, or even reopen – nothing is lost! Closing obsolete issues is an important way to help maintainers focus their time and effort.