[Nix-dev] What is the end game?

[Daniel Peebles]

I'm trying to avoid making this conversation about Hydra (or services)
specifically, but agree with the points you're making.

To try to steer the discussion in the direction I'm most interested in,
what if binutils had a release.nix in its repo? How about gcc or clang?
What would the expressions look like in nixpkgs? The options I can see:

1) nixpkgs is full of e.g., binutils = (import "${fetch* { url =
"url/to/binutils"; sha256 = "abc"; }}/release.nix").build
2) Duplicate the release.nix of binutils in nixpkgs
3) Some combination of 1 and 2, where metadata, name, dependencies are
expressed in nixpkgs, but build instructions are in the repo's release.nix
4) ???
5) profit

Actually, I'm not sure #4 and #5 are relevant, but I couldn't think of
other options.

#1 seems impractical because a single nix-env would result in thousands of
fetchurls
#2 seems undesirable due to duplicated information
#3 seems like our best bet, but I don't know what that would look like



On Sun, Aug 30, 2015 at 9:54 AM, Domen Kožar <domen at dev.si> wrote:

> Or we could, as any software, tag and release hydra so that users can
> fetch working versions for easier learning curve.
>
> On Sun, 30 Aug 2015 15:38 Nicolas Pierron <nicolas.b.pierron at gmail.com>
> wrote:
>
>> 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/
>> _______________________________________________
>> 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/20150830/580117a0/attachment.html