Persistent packages on Steam Deck using Nix

It really depends on how you start your programs. If you wrap your compositor with nixgl then everything started through your compositior inherits the relevant env vars (LD_LIBRARY_PATH etc.) and you don't have to wrap the programs separately.

The opposite. Everything must be in /nix.

Which itself is derived from the logic-defying diagram of the holy trinity: https://en.wikipedia.org/wiki/Trinity

Patches are welcome :)

Not just senior community members, DetSys is the company of the creator of nix.

This installer and the relationship between DetSys and Nix has also been subject to major criticism about conflict of interest between community interests and DetSys, since everyone agrees the official Nix installer has major issues. "Determinate Nix" (as DetSys calls the nix configured with their installer) also enables features that are the de-facto way to use Nix these days, but are disabled in the default distribution because of... let's say... commitment issues.

If you want a community run alternative, try Lix. They have a version of the DetSys installer too - and they actually cut releases of nix instead of building moats around it.

https://lix.systems/

Not the OP, but I work in consulting. When I was still hands on keyboard, this would have been very helpful for the clients who don’t provide their own hardware or environment for us to use. I also do work for extremely large organizations who have literally dozens of different stacks accumulated over the decades.

In addition, I play with all sorts of open source tools and they often come with their own tool chains and expectations. Python version management in particular benefits a lot from this level of isolation. Instead of figuring out the different version management tools for each stack I use a higher order environment management tool in Nix.

Some others are solving these issues with containers, and that’s a part of the nix strategy as well.

The most recent offenders were nodejs and kustomize used as part of a test flow orchestrated by a Makefile, run both locally and in CircleCI.

People will just install the latest version and start hacking away, and now you've got all this code that depends on that version. Backwards compatibility ain't perfect, so maybe several years later the original author doesn't work here anymore, so tests are breaking in subtle ways when you install what's the now latest version and there's nobody to ask what the "right" version is.

But since we're a culture that uses these tools (though I wish we weren't), this story has played out several times so different projects need different versions--you can't just discover the right one once and leave it installed in your system, you have to install the right one for your project and change it when you switch to a new project.

For the most part these are go projects, so even though there is language-specific dependency locking via go.mod and such, dependencies which aren't go libraries but which are nonetheless needed to work with the project (e.g. make) are left as an exercise to the reader. Make is pretty well behaved, I haven't had to do much version antics with it, but I wouldn't say that's the norm.

When I find one of these repos I put my archaeologist hat on and write a flake.nix to provide whatever the dependency is, and then I walk the version backwards until it starts working. That way next time I'm in that project I don't have to go through that exercise again.

To make matters worse, people often try to help by adding entries to the makefiles which download the correct version for that project, but some people have the newer arm chips and others are still on x86 so confusion of a new kind ensues. Of course it's easy to fix these scripts to detect the local architecture, but that's a whole extra step.

And then maybe you're trying to make this stuff work in CircleCI or somesuch, and you don't want the workflow to just be reaching out via https and blindly running whatever comes across the wire because who knows if it'll be the same thing tomorrow, so you add hash checks, but once you've got the hash checks and the architecture checks and you're checking the right hash for your architecture... we'll you've basically got a poor man's flake.lock at that point, might as well use the same nix config in both places rather than use homebrew or apt or whatever locally and then figure out how to do the same thing via circleci orbs in yaml and god forbid you have to do it in prod too so now there's a Dockerfile... Having a single source of truth for dependencies and using it everywhere is super handy.

That's work. Another example is in my personal projects. I use helix, so there's a .helix/languages.toml in my repo which defines the language servers that I'd like it to use for that project. But merely pointing helix at the language server isn't enough, it also has to be on the PATH. My older projects are using mypy, and my newer ones are using pyright (python type checkers).

Sure I guess I could just install both at the system level everywhere I go, but when I clone the project on a new machine I want to have everything work right away--I don't want to start coding and then wonder why my editor sucks and then go discover and install the right LSP and then resume coding. I'd end up with a smattering of different versions installed across all of my devices, even for the same project. If I find a bug which happens on this machine but not that one, I'd have a much harder time knowing where to start re: debugging it.

Finally there's this idea that maybe you don't even have to clone the repo, you can just reference the app you want to run from anywhere. I invoke some of my tools like:

    nix run git+ssh://git@github.com/myorg/myrepo -- mycli --best-arg

Nix knows how to set up the environment for running the app (the one I have in mind is written in python, so a certain version of poetry is involved etc...) so I really don't need the caller to think about that environment at all. I like this because it decouples the orchestrator from the executor. So if I can manage to get something working locally with one of these commands, then I can go put the command someplace weird like in an Airflow DAG (kubernetes pod operator, NixOS image) and I have a pretty strong assurance that it'll work the same in the remote environment as it does locally.

From the perspective of a nix user, these problems are all the same problem and they're everywhere and nix is the only thing that solves all of them at once. My feeling is that from the outside, they look like separate problems, and it's not clear just how many of them are solved by nix--so the juice doesn't appear to be worth the squeeze.

Scripts are the main place where it matters tbh - most language ecosystems have their own way of doing this stuff, if you can stay within the language you're fine. But if you (or your client) have a culture where people throw in awk/grep/sed then there's just no real alternative. Or if it's a polyglot project where you have three different languages (including shell) then you may not be able to use a single language package manager.

Agreed. I use a flavor called EndeavourOS. Very happy with it. I have had bad experiences with other flavors in the past like Manjaro. I think yay is peak for me so far.

Installing nix from a package repository feels very wrong.

You can always get it from a AUR on arch which is user repos if thats the case, kinda like Ubuntus PPAs.

Haven't tried adding Nix packages as non-Steam games, but you can use Home Manager to create user systemd rules.

I haven't tried it personally, but from what I can tell, if you have a binary you can give a path to (and setting up env vars if needed in the "launch arguments"), you should be able to add it as a "non-Steam" game, and anything set up to start automatically via systemd seems to be properly started up in game mode, so I don't see why this wouldn't work!

You're just making me wish we had a phonetic glob :)

Great note, thanks--that one now makes sense.

Same with flatpak, both use deduplication