Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

env: Consider adding separator option for prefix env vars #218

Open
lilyball opened this issue Aug 31, 2022 · 1 comment
Open

env: Consider adding separator option for prefix env vars #218

lilyball opened this issue Aug 31, 2022 · 1 comment
Labels
enhancement New feature or request

Comments

@lilyball
Copy link

Is your feature request related to a problem? Please describe.

I can define an env var with prefix to prefix a path onto a :-separated PATH-like variable. However there's no convenience for prefixing onto other types of variables. In my case I want to add something to NIX_CONFIG, which is a newline-separated variable. And today I have to write this like

{
  env = [{
    name = "NIX_CONFIG";
    eval = ''"builders = "${lib.escapeShellArg builderConfig}''${NIX_CONFIG:+$'\n'"$NIX_CONFIG"}'';
  }];
}

Describe the solution you'd like

I'd like to have a separator option which I can set to something other than ":".

This also requires some way to disable the realpath invocation. That makes sense for PATH-like prefixing but not for other variables. One possibility here is to say "if you define the separator option it disables path expansion, even if you set it to ":"". This would allow my definition above to look like

{
  env = [{
    name = "NIX_CONFIG";
    prefix = builderConfig;
    separator = "\n";
  }];
}

Describe alternatives you've considered

With this I'd also like to be able to suffix the variable too, not just prefix. That is possibly useful for PATH-like variables too, although much less common, but e.g. in my case I'd prefer to suffix instead of prefix to ensure my definition actually works even if the inherited $NIX_CONFIG already tries to define the key.

@lilyball lilyball added the enhancement New feature or request label Aug 31, 2022
@zimbatm
Copy link
Member

zimbatm commented Aug 31, 2022

Why not? It makes me think of wrapProgram, maybe the env option should be modeled after its options, so there is some transferable knowledge there.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants