[Nix-dev] What is the end game?

[Anderson Torres]

My two satoshis on it.

Looking at our famous brothers as Slackware, Gentoo, Debian, Arch
etc., we can trace and forecast a situation:
* Small projects can be handled by single developers, with high
independence from upstream maintainers (as myself taking care of mpv
and xiphos);
* Medium and huge projects can be handled by sub-teams, such as "GCC
NixOS team", or "Haskell NixOS Team"; these huge teams will be more
tightly connected to upstream, with developers in common.

In practical terms, I prefer the expressions centralized on our Nixpkgs release.

2015-08-30 13:12 GMT-03:00 Nicolas Pierron <nicolas.b.pierron at gmail.com>:
> 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/
> _______________________________________________
> nix-dev mailing list
> nix-dev at lists.science.uu.nl
> http://lists.science.uu.nl/mailman/listinfo/nix-dev