Using nix in existing projects

Help
1

I would like to use Nix for development at work. We have a variety of projects, mostly written in C++, and each in their own Git repository. Some of the projects are libraries, which may depend on other of our libraries, and some are applications that use those libraries. Is there a good way to use Nix to work in this setup?

What I’ve tried so far is to make a flake.nix per project, with the build tools and dependencies. I’ve managed to build a few of our projects this way, with flakes pulling in other flakes as dependencies as necessary. This… works, but a couple of things could be smoother:

  • Making debug and release builds of everything is possible but kind of a mess. Every flake gets a debug input that may be true.
  • Each flake points to a commit in a git repo. Updating a dependency means updating these commit pointers in a bunch of flakes.

These seem small but add up to quite a lot of ceremony when working with Nix. The main problem is that I have a lot of versions of each app/lib in play at any time (if nothing else, there’s the last release of the main branch, usually there are one of two release branches as well), and for debugging there are also debug versions, and these add up to a bit of a combinatorial explosion of stuff that I have to keep on track by hand.

Does anyone have experience with using Nix in these kinds of large, interdependent projects that weren’t built with Nix in mind?

2

I feel like that’s a very weird way to do that. mkDerivation has features for stripping debug symbols, and you can use separateDebugInfo = true; to add them back. As long as you use mkDerivation properly hacks like this should be completely unnecessary.

Even if you work with languages that don’t support this, or if debug builds mean more in your context, a passthru seems far more appropriate.

Yep. You could consider a company-wide flake registry, or you could have a central flake that imports all the others and sets them up as a package set. Then you only need one dependency, and this package set can also be used for the final full-system artifact builds.

It’s hard to give you a tailored solution with what you’ve told us, though; ergonomic cross-project structure depends significantly on your dev, CI and deployment workflows. A good workflow can definitely be achieved, but I think you’re into “ask a consultant for a quote” territory, especially given this is commercial activity.

1 Like