Daniel Peebles <pumpkin...@gmail.com> writes: > 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.
We do something like this. https://github.com/monstercat/monstercatpkgs I guess I could have chose to keep the expressions in the git repos, but decided to stick with nixpkgs conventions. We host all of our internal code on a vpn (zerotier). We found fetchgitPrivate was too much of a hassle. Right now our production machines point to a nix-serve cache (also on vpn) where the code is built. Mostly because I haven't got around to setting up Hydra yet. Cheers, -- William Casarin PGP 0x6D3E2004415AF4A3 https://jb55.com _______________________________________________ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
