[Nix-dev] What is the end game?

[Nicolas Pierron]

I don't think the #1 is unpractical, if you consider that these
fetches are properly mirrored, which we currently do with channels.

On Sun, Aug 30, 2015 at 5:34 PM, Daniel Peebles <pumpkingod at gmail.com> wrote:
> 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
>
>



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