Thanks for being understanding. I wouldn’t say I’m new to nix, I first started using it as a package manager for macOS ~2019, and then got more deeply involved to try and use it for CI in 2020. In 2021, I’ve submitted a few PRs to nixpkgs, including fixing the fundamental iOS build stuff, and I’m using it on my desktop m1, along with a custom derivation for macOS apps/packages that I meant to upstream awhile back. I’ve got ~600 lines of nix locally to install various macOS GUI apps that aren’t in nixpkgs.
However, I do feel like I still don’t know that much and am still an outsider? The big issue being that there’s so much complexity and special cases, as well as multiple sources of documentation. I think I wound up pulling a lot from both the nixos and nixpkgs documentation, as well as having to spend a considerable amount of time reading nixpkgs itself. Which isn’t great. Error messages have often been unhelpful as well (though I think at least some of the specific complaints I had were pending and may have been merged right now).
Eg an update broke my darwin-configuration.nix awhile back, and all I know is that the override I had to add my installApplication to nixpkgs.darwin does not seem to be working (I get ‘installApplication missing’ in my other packages). And I haven’t fixed it because I perceive it as requiring a ‘deep dive’ (I took a stab at it today and so far it looks like it’s an accurate assessment after 20-30 minutes). But I digress.
I think I was a little too ambiguous for what I’m doing. I have a backend I’m working on where I need to set a few shell variables - further down the line I figured I might take a stab at setting the environment packages and using --pure so I would have a consistent environment regardless of updating my system packages. So I’m not building software so much as executing various commands or launching docker/docker-compose instances. Basically I’m trying to use it as a power-virtualenv that can handle any kind of packages, not just python.
So basically right now my default.nix consists of a few variables being set and a shellHook to run a single mkdir -p command. Typically I enter the environment with just nix-shell.
While what I’ve been doing is working, this discussion has raised some doubt in my mind that I’ve been doing things correctly.
Although as I check, both my Arch Linux and macOS machines even have nix develop (2.3.15 vs 2.4pre I guess). And I guess I need a much longer command to keep nix itself up-to-date. Though to be fair, maybe this is handled by darwin-rebuild. Or maybe I need to do nix upgrade-nix? sigh. At one point I knew this.
Well, right now I’m using mkShell. I’ve heard of buildEnv somewhere, but trying to find the tradeoffs via Google search doesn’t yield terribly helpful results.
Even in the first one, someone is already having to delve into the source. And it doesn’t really answer the question of what each one is for, and what guarantees it makes. The problem with delving into the source to understand stuff is that it’s impossible to know what’s ‘guaranteed’ behavior as part of the function contract, and what’s current implementation-specific stuff that’s presumed internal. So it makes it hard to build on stuff without it breaking.
Anyway, sorry for my long comment and derailing the thread. Wasn’t my original intention to go this in-depth, I just figure that most people who run into these issues end up simply going silent, so the people that are left are the people that tend towards being willing to tolerate the status quo. When nix works, it’s fantastic, and actually easier to use than some other package managers. A basic derivation is relatively clear about what it’s pulling in. It’s mostly just the learning curve, like where simple questions like this wind up leading to a complex discussion.
I’m not sure if it’s just better documentation or if there needs to be a stronger curation of what’s functionally ‘external’ for most users (simpler) vs ‘internal’ for people working on nix itself (more complex).