Got familiar with NUR and even contributed xonsh-xontribs
Got fed up with the static library issue and not being able to run things like Pieces for Developers (note: this is one of several I’ve struggled with), so I’m not running Mint + flatpak + nix/home-manager on a separate partition to see if this workflow is better
Some of the things I’m still struggling with after all this time are:
I like the concept of devcontainers, but I hate managing separate config for my local .zshrc/.bashrc and what I want in the container
Ditto for remote SSH hosts that are not nix based
When using some GPU enabled Nix packages via home-manager in Mint, I’m consistently getting Error: couldn't find RGB GLX visual or fbconfig. It’s led me to drop packages from Nix and use Flatpak or released .deb packages provided by github instead
appimage-run is OK, but not 100% successful.
I’m now questioning if I want to continue down the Nix path, or if homebrew might be better for me in my use case. I love Nix, but it just feels like a fight sometimes to use unsupported packages.
Does anybody else struggle with things like this? Am I the only one?
I mean, if you are deep within Nix for a year, shouldn’t you know if it’s right for you? If you find yourself struggling all the time trying to do things that are not a good match for NixOS, then just switch so something else.
DevShells, nix-direnv, and their more beginner-friendly pendants like devenv are some of the main reasons to use Nix/NixOS for me. If you find that you prefer a Nix-less solution for this, maybe it’s not really the right tool for you.
I am not sure what the issue is here, honestly. Isn’t that always the case that things are annoying if your favorite tools are missing on remote hosts. If you cannot use some of the solutions that allow to use Nix without root access, then you’re out of luck. Running Nix stuff requires Nix, it’s just a basic requirement. If Zsh is missing, you cannot use your .zshrc, same story really.
It’s a well-known issue that programs that use the GPU are an issue when running on Non-NixOS systems. There’s nixGL that solved most of these issues for me, but your experience might of course be different.
I agree with the response above, to me the whole point of using nix for dev is ephemeral environments that don’t clutter the global PATH and config with stuff that’s really only relevant to one project.
NB they are not containers, they are shells. There is no other isolation from the host system unless you set it up as such (I use an overlayfs on my $HOME to avoid build systems dumping crap in my home dir, for example).
same as above response
nixGL exists but doesn’t work 100% of the time, hence I just use NixOS wherever possible. In any case my reason to use NixOS was to centrally manage the config for remote hosts, i.e. I wanted to use NixOS anyway
I package the thing with nix and then don’t need to use such a solution. Though I don’t really have the need to run random appimages off the net.
Also you really made more work for yourself with the whole impermanence deal, sure it has upsides, but it forces you to opt into every bit of state right away rather than letting you migrate more gradually.
I don’t disagree. However, I feel like the nix solutions (I use devenv.sh now mostly) are great for individual environments, but aren’t as helpful when working with a team. I created a devcontainer for one of our monorepo projects, then found how hard it was to propagate my zsh config into the container (since it was nix/home-manager based).
That led me to the thought of should my config be in nix if I need it outside of nix? I’m starting to think my neovim/tmux config are better off in chezmoi where I can use it in other places rather than in nix, and having that thought bothers me.
I think what I’m trying to convey is that Nix as an OS + package manager is great, provided you can use those packages that are in nixpkgs or NUR. Ditto for using nix simply as the package manager, except for the GPU limitations.
I think the biggest weakness is when you are on that boundary of needing something not in nixpkgs. That’s where things get frustrating. It makes me wonder if that’s something that’s missing in the Nix offering that would make adoption easier/better.
On the contrary, I set up a Nix development environment for a work team (embedded, plenty of free and proprietary compilers for various ARM cores, DSPs, and in-house hardware developments) and having the development environment description as part of the project source code is fantastic. We didn’t have a “works on my machine” issue ever. And getting started is as simple as checking out the source and grabbing a coffee while it downloads 150GB of toolchains.
Of course, that is, IF you can convince your team that this is a good solution and get support for a team-wide rollout. That can be a lot harder indeed, depending on your seniority and the type of people in your team.
It’s probably better in a different place if you regularly need to deploy it to systems that don’t run Nix.
I don’t know, when a package sucks, it usually sucks on most distros. When it’s well done, it’s also often easily packaged for Nix. Have you tried creating new packages for Nix? I found it quite surprising how far you can get by looking up something similar in Nixpkgs and taking that as a blueprint. But it really depends on what you are packaging.