Development/Release workflow with Nix Flakes

Hello,

I have two short questions regarding real-world use of Nix flakes.

  1. For local development, I have a shell.nix file with the libraries my C++ application depends on, along with supplemental tools such as a LSP server, code formatter, etc. There is a separate default.nix file that I use for release builds which omits these development dependencies. I have set up a Nix flake for my project, but it’s unclear to me how I would include these supplemental tools and make them available when using nix develop. These tools should not be part of the output file that users receive, so where in the flake do they go? Upon reviewing the documentation there’s a devShell attribute that can be used for this and seems to do what I intend :slight_smile:

  2. For development, I use shared libraries for my application’s dependencies. For release, I use Nix to build a fully static binary using pkgsMusl. The downside of this approach is that it requires building several large dependencies from source. Is there a way to specify two flake.nix files, one of which can be used for development (dependencies are shared libraries) and another for the release build where everything is static?

Thank you.

@eee, isn’t it just down to how you write your output attributes?

Your devShell attribute could provide the usual development environment with regular linked packages, but then the actual packages.${system}.topSecretProject attributes could build with pkgsMusl.

Or you could have packages.${sys}.project and packages.${sys}.projectStatic ?

2 Likes

Thanks Cole, that actually makes a lot of sense and it didn’t cross my mind! I think that should solve my problem cleanly :slight_smile: