Change:
description = "Run commands in the same FHS environment that is used for Steam"; mainProgram = "steam-run"; name = "steam-run"; <ins> # steam-run itself is just a script that lives in nixpkgs (which is licensed under MIT). # steam is a dependency and already unfree, so normal steam-run will not install without # allowing unfree packages or appropriate `allowUnfreePredicate` rules. license = lib.licenses.mit; </ins> }; }; }

Discussion:
Currently, Steam-Run depends on Steam itself. This results in the annoyance of having to allow Steam as an unfree package, besides being a needless installation in itself. Note that used to be decoupled and considered fully free. This unwanted dependency has appeared sometime during 2021 or 2022. Try to install without having unfree packages allowed, from 22.11 channel. Try again, adding to your Now it refuses to evaluate because you haven't enables in your . should preferably not be or depend on unfree packages at all. Even if it does, it should definitely not depend on Steam application itself. It's supposed to be a general-purpose tool to run Linux binaries, not just Steam games (right?).
Since we have a free steam-run again, but it's not well exposed yet (it's available as ).
Something else that bothers me is that steam-cmd requires steam-run and so steam-cmd pulls in an entire X desktop environment, steam-cmd is designed for hosting dedicated servers mostly so this is a waste of time, and precious disk space on a VPS. IMHO steam-run should be spun out in to a separate non-steam thing and then extended to include the stuff needed for these different environments, I've seen it recommended for running FHS binaries in situations that have nothing to do with gaming, so it makes sense here to generalize it.
I think it's time for a fhs-run attribute. Everything appimages need + anything that doesn't add significant cost would be a good starting point. A headless variant for command line tools would also be interesting, but it's harder to define a solid base here IMO. We currently have multiple of such lists of packages and we ought to deduplicate that. steam-run would become a specific fhs-run that adds steam and a few game-specific deps in it. Similarly, we could have a lutris-run that might have the same game-specific deps plus some extra for lutris runners.
The steam-run license issue came up again in a discussion in social media. I support creating a general purpose tool and use it as base for specialized ones! It's also important to document the tool in a way new users find it when needed and don't have the experience that NixOS is broken (binaries don't work).
Is this relevant to the issue?
No.

Another great option is to use flatpak, for example: I'm pretty sure they both use the same container tech (bubblewrap) anyway.
Today, I had a problem where a Ruby Bundler package wouldn't work because it expected a FHS environment, breaking the build of my Jekyll site. Then I remembered the comment here. I'm happy to report solved it just like the package would in the old times. Therefore, this issue is solved. I still do agree that one or more separate "fhs-run" programs that would not have as many dependencies as would be good to have, like suggested, but it's not what this issue is about.