[Nix-dev] Nix for internal projects and monorepos

[Ryan Trinkle]

We (Obsidian Systems) use nix-copy-closure to push the binaries to each
deploy target, update the system profile reference, and then call the
activation script.  So, our target servers never need to evaluate nix code
during a deployment.  My understanding is that nixops does things in a
similar way.

On Fri, Mar 24, 2017 at 4:01 PM, Daniel Peebles <pumpkingod at gmail.com>
wrote:

> Hi all,
>
> I've been ruminating about the best way to deal with an internal (to a
> company or otherwise private) package set with Nix, especially with a
> monorepo.
>
> My first inclination would be to leave Nix expressions (as default.nix)
> alongside the project source code, and use path references in those
> expressions (e.g., src = ./.;) to actually build the project.
>
> The difficulty arises when you want to deploy this stuff to production.
> Unless you want to ship your entire internal source tree to each box with
> Nix on it (no, I don't in practice want to be building my apps in
> production, and would use a Hydra/binary cache), you're going to want to
> "lift out" the nix hierarchy from your source code hierarchy, replace the
> src links with fixed-output derivations somehow, and ship the whole thing
> as a channel. I don't know of any tooling to do that, or how to do that
> effectively. It seems like it would require some tooling on the Nix side to
> work nicely.
>
> The alternative would be to adopt a more nixpkgs-like approach, and
> maintain a separate tree of packages that point into fixed-output
> references into the actual codebase. That unfortunately means moving the
> build spec farther away from the code it builds, and although it might be
> necessary in the case of nixpkgs (because we don't control all FOSS
> projects), it seems like we can do better.
>
> How do other people tackle this problem? Does anyone maintain a reasonably
> large internal Nix package set?
>
> Thanks,
> Dan
>
>
> _______________________________________________
> nix-dev mailing list
> nix-dev at lists.science.uu.nl
> http://lists.science.uu.nl/mailman/listinfo/nix-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.science.uu.nl/pipermail/nix-dev/attachments/20170325/4261fb6e/attachment.html>