[Nix-dev] Nix for internal projects and monorepos

[Tikhon Jelvis]

Pushing a Nix closure is what I was going to suggest too: if you have Nix
on the target machines, it seems like the best option. You can have your
cake and eat it too: you get Nix's infrastructure and verification without
having to build on your deployment machines.

We've been using Nix at work but still haven't settled on the best way to
do things. The Nix expressions for our internal packages are in the repo
with the code which works fine, but I could see switching to keeping all
the Nix scripts separate. In practice, we almost never edit the Nix code at
the same time as project code—we occasionally spend dedicated time
improving our build setup, but after we got it working initially we haven't
had to make any changes as our project grew.

We looked into using nix closures ourselves, but for internal reasons we
couldn't have Nix on our deployment cluster. Instead, we're shipping
statically linked Haskell executables that are then run with Hadoop.
Building statically linked Haskell binaries with Nix was a bit of a pain,
but now that it works deployment is easy. Also, it still doesn't build
statically on OS X, but we don't care because we're not deploying to OS X
servers :).

On Sat, Mar 25, 2017 at 6:28 AM, Ryan Trinkle <ryan.trinkle at gmail.com>
wrote:

> 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
>>
>>
>
> _______________________________________________
> 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/7e3018f5/attachment.html>