It understands \n if I recall correctly. You can also write regular bash, use templating tools, etc. Just use the nativeBuildInputs parameter if you need a binary that isn’t provided by stdenv.

Another alternative approach would be to add a duplicate desktop file, but to write it declaratively using Home Manager:

# in home.nix
home.file.".local/share/applications/firefox.desktop".source =
  pkgs.runCommand "firefox-desktop" { } ''
    cp "${pkgs.firefox}/share/applications/firefox.desktop" "$out"
    substituteInPlace "$out" \
      --replace-fail "Terminal=false" "Terminal=true"
  '';

# - or -
home.file.".local/share/applications/firefox.desktop".text = ''
  [Desktop Entry]
  Name=Firefox
  Icon=firefox
  Exec=firefox --name firefox %U
'';

It would be possible to DIY this with user activation scripts, but I don’t really see a value in doing that over the symlinkJoin.

Since the desktop files come directly from a package you’ll need to change the package you’re installing. This works best if you use the postPatch phase of symlinkJoin:

pkgs.symlinkJoin {
  inherit (pkgs.firefox) pname version;
  paths = [ pkgs.firefox ];
  postPatch = ''
    # String replacement example - will run the app in a terminal
    substituteInPlace "$out/share/applications/firefox.desktop" \
      --replace-fail "Terminal=false" "Terminal=true"
  '';
}

The reason for using symlinkJoin here is that it creates a package with the same outputs as the original Firefox, but with this bash script having run. You can use this like any other package:

let
  firefox' = <...>
in
{
  environment.systemPackages = [ firefox' ];
  # - or -
  programs.firefox.package = firefox';
}

Note that symlinkJoin has special handling for postPatch, but ignores all other stdenv phases, so you need to do everything in one bash script. You can use all the parameters for runCommand though, such as buildInputs and nativeBuildInputs - e.g. for compiling sass in a wrapper derivation.

In some cases it’s useful to also inherit meta or passthru because it’s used in some nixpkgs/nixos sanity checks, but it’s usually not required.

Another approach would be to use overrideAttrs, which will also work but will cause Nix to rebuild the package from scratch. This might be fine or even desired in some cases, but you probably don’t want to do that in this case.

Also coming from Arch will induce a bit of a culture shock regarding documentation as the NixOS wiki is just… not very good. It’s neither complete nor reliably accurate for the current release. And some wiki pages are actually just snippets with no explanation for either what they do or why they do it.

The matter of flakes is complicated. Yes they are experimental, but in reality most Nix users use them despite that. I’m a bit on the fence on whether you should start with flakes because they do add some complexity. You can copy paste a sample flake configuration from the Internet (there are many but they all do exactly the same things) and you’ll probably be fine but telling people to just copy paste code they don’t understand feels wrong as well.

Regarding documentation… I wouldn’t go as far as saying you should avoid it entirely but it is in a very unfortunate state with a lot of wiki pages being outdated or just containing snippets that do things in very weird ways, or are over engineered to the point of being incomprehensible.

And that’s if someone bothered to write up anything at all. It’s a bit sad but reading from the nixpkgs GitHub (or other people’s dotfiles) is sometimes the only way to get certain information, such as valid values for package overrides.

As a Home-Manager user I would argue it’s not really worth it. It has it’s moments for some applications but most of the time it’s the same experience as editing the config files directly. Except instead of INI or TOML it’s stringly typed Nix attrsets and you need to rebuild the entire system instead of restarting the app. Not exactly a huge improvement.

And that’s when you’re lucky enough that what you’re configuring can be mapped to attrsets. Styling Waybar via Home-Manager means writing CSS but it’s a multi line string in Nix with no appropriate editor support whatsoever, and writing custom actions for Nixvim means writing Neovim-Lua but… that’s right, in a multi line string.

On a more positive note, I will second the recommendation for the NixOS & Flakes Book, I found it to be much more useful for getting my head around flakes (and Nix in general since I started using them fairly early on in my Nix journey) than e.g. Vimjoyer’s videos, which are good but their repositories were really really cryptic to me at the beginning.

I’m not sure why nix-env is so slow exactly but it’s the wrong tool to use anyways as it just throws away everything NixOS has going for itself in favour of pretending to be a normal package manager. You really just want to use the configuration file.

The “normal” way to install packages in NixOS would be using environment.systemPackages. The various programs.<name> options are intended for packages requiring additional setup, like shells or desktop environments (e.g. iirc for sway it creates a systemd target and adds the .desktop files for login managers to see it). Weston has a package but not an option, so you’d have to figure that additional stuff out yourself (but running Weston from a tty should just work).

There are additional ways to install packages for single users or using home-manager but you don’t need those.

This does kinda demonstrate why (I personally think) NixOS is so hard to learn: There’s a million different ways to do anything and each has it’s own weird gotchas. And critically most of them, even when they are honestly just legacy cruft, are not actually deprecated and may even have users advocating their use, or even if they don’t nobody bothered to remove that part from the wiki (if it was ever there to begin with).

You can also see this in the flake/channel split: One person in this very thread is telling you to use flakes, while another is telling you to stick with the default (channels).

And in some (fortunately relatively rare) cases even things that everyone agrees are bad ideas still get promoted in official documentation or other prominent places, like using nix-env -i under any circumstances, ever.

And it is definitely a learning problem you are having. You are facing the same problems as a new Linux user who just installed Manjaro with KDE 6 on Wayland and is wondering why apt-get and xrandr are not working even though those are accepted answers on Stackoverflow posts from 2012. Of course as experienced Linux users we know why, but a new one has to learn a lot of stuff before “getting it” and will probably stumble onto poor advice more than once in their journey. (And learning Nix is arguably worse than learning Linux for the first time, but that depends a bit on your exact experience and background.)

If you stick to learning NixOS there will be a point when these things seem trivial, but it will be a lot of effort to get there. Is that effort worth it? Well, if the term “declarative package management” doesn’t mean anything to you, maybe not. You do sacrifice a lot of things “just” to declare your entire system state in one configuration file (or more likely, directory). But I do think the things Nix does are really cool, if you can get over the, uh, everything.

『合コンに行ったらイケメン女子がきた』/“I Went to a Mixer and a Handsome Girl Showed Up” by Murakami

Official Pixiv ^JP | Official Twitter/X ^JP | Mangadex ^EN | Dynasty ^EN