Hi all,
I’ve got a rather interesting question (well, interesting to me anyway): what is the common practice for creating .nix files that set up build envs that have specific requirements (i.e. specific commit from a particular library, or specific library build config like static or shared, etc.)? I’d love to write a .nix file that sets up a dev env (and allows the building) for a project I’m collaborating on, but it has specific requirements like building a lot of it’s libs as static (though we’re hoping to make this a configurable option) and it also has some deps that aren’t in nixpkgs. Is the usual practice to just put all of this in a single .nix file, or to split it into several? Is there a good project I can look at as an example?
I’m not sure you’ll get a one-size-fits-all recommendation from the info here, but I generally just start with one file and wait until that starts to feel cumbersome to split stuff out.
The only case that leaps to mind where I’d recommend something else from the start is if you already know you’re going to end up packaging stuff that isn’t in nixpkgs and you are pretty sure you’ll want to upstream at least some of them. In that case, I’d split those out into separate files that use nixpkgs’ idioms.
(This may feel complex, but it’s hard to know what it’ll look like. pkgsStatic might be a fine answer for your shared/static needs and overrideAttrs may suffice to set specific library versions as long as the expression in nixpkgs doesn’t need other fixes to build that version. If so, you may just need a few lines per library–short enough that I think it would be counter-productive to spend time setting up a file for each one.)
Hopefully someone will feel like they have a good example to share. It may also help to clarify whether you’re hoping to build the project itself within a Nix expression, or just use Nix to provision a shell environment with all of the prerequisites where you can invoke the build commands yourself?
I’m hoping to both build the project and get a dev env for it. The deps don’t need any patches or anything, we just need later revisions of the deps in question for the most part.
I’ve run into this problem too: find a “good way” to organize a project with multiple interdependent components, which generally aren’t in nixpkgs.
After several unsatisfactory attempts, light for me dawned on reading this: [Flakes aren't real and cannot hurt you: a guide to using Nix flakes the non-flake way - jade's www site]. My writeup here: [Building your own project with nix].
Non-trivial project using this pattern: [GitHub - Rconybea/xo-nix2: package XO libraries using nix flakes].
Summary:
- toplevel directory has a flake.nix, with a pkgs/ subdirectory.
- pkgs subdirectory has a .nix file for each project component.
- toplevel flake.nix uses overrides so that configuration is centralized there.
Bonus: all the revision pinning is done from flake.nix, so you don’t have to deal with subproject hashes.
Ooooo thank you for pointing me to those resources, I’ll definitely check them out!