Setting LD_LIBRARY_PATH in one’s HM config would be inadvisable.
Instead, the problematic packages should be packaged correctly (or if you don’t know how to fix said packages, at least they should be reported to the nixpkgs github repo if they come from nixpkgs.)
I am surprised if setting LD_LIBRARY_PATH yourself is actually something that is not supposed to be done. I’ve come across many packages where you have to add it to LD_LIBRARY_PATH yourself. And many accepted solutions to problems on this forum involve setting that path.
Having LD_LIBRARY_PATH set at all is discouraged on nixos, though it is, of course, unavoidable when using nix on other distros.
This is because setting it can alter the dynamic linking behavior of nix-packaged binaries, potentially causing failures, as well as potentially causing undeserved successes of what you package yourself, which both hamper reproducibility.
What situation did you encounter that made you think you needed it? There are basically always solutions that don’t involve setting it.
You’re confusing the types of the nix language itself with the types of the nixos module system. The types of the nixos module system determine what nix values are valid for the option and how they merge. They are, in principle, totally unrelated to the types of the nix language itself, which are what builtins.typeOf is giving you.
Those all sound like development applications, for which they should at least only be set in the dev shell you’re working in, rather than system-wide. I suspect there are ways to make it work without even setting it in the dev shell, but I’m not sure on that count. At least when setting it through the dev shell, you limit potential problems to programs started from the dev shell.
Thank you for the clarification. That still leaves me with the question of how to declare a envVar? From all that I heard, it still sounds like if the nixos module system determines the type is envVar they should be merged if declared in different modules?
Whoever created the option needs to define it that way.
Or you create your own option with the types.envVar type and set the corresponding envvar in home.sessionVariables with its final value.
But again setting LD_LIBRARY_PATH is a massive code smell as 3 of us warned above.
Yes, it has a merge function that comes from types.separatedString:
This is not necessarily true. See Nix-system-graphics: Seamless nix graphics on any Linux distribution for how to get seamless graphics drivers on non-NixOS with the same limitations as NixOS. I also drafted a possible low-tech alternative that would achieve the same in that thread.
As pointed out earlier, types.lines is mergeable so this works. Thus you can extend environment variables in modules. I also tested adding lib.mkOrder which does effect the order these are combined
I imagine that would get rejected because most envvars do not take multiple values with : as a separator, and what you have set up isn’t supported anyway.