[Nix-dev] What is the end game?

Nicolas Pierron nicolas.b.pierron at gmail.com
Sun Aug 30 15:38:29 CEST 2015


Hi Daniel,

On Tue, Aug 25, 2015 at 5:42 PM, Daniel Peebles <pumpkingod at gmail.com> wrote:
> Let's say for a moment that Nix has taken over the world, and every open
> source project now includes a default.nix or release.nix in its repo root.
>
> What does nixpkgs look like in this world? Does it duplicate the individual
> package .nix files in their respective repositories? Does it only duplicate
> minimal information (dependencies and meta) from the remote repositories?

If we were in such world, then the module would probably be best
handled by upstream maintainers.

The way NixOS modules are working, we need all of them before
evaluating any configuration, thus we would need to have a copy of the
configuration file, even if we have to download it.  In such case, it
makes sense that NixOS list of modules would be built out-of an
aggregate of fetched resources.

Thus, if we ever do a copy, we should do it with an url and a hash,
and have one of the multiple output of packages be the NixOS module
that we will aggregate, as-if it was a generic post-install script.

Then, the problem with Hydra, is slightly different.  Currently hydra
does not provide any stable ("tagged") version.  I guess we could
experiment the previous suggestion, but I would prefer to have
multiple instances of this problem before attempting any generic
solution as described above.  In the mean time, I think having your
own copy of hydra, and using it to aggregate the module which is
inside might be the best solution.

-- 
Nicolas Pierron
http://www.linkedin.com/in/nicolasbpierron - http://nbp.name/


More information about the nix-dev mailing list