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 <[email protected]>: > 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 <[email protected]> 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 <[email protected]> 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 <[email protected]> >>> wrote: >>>> >>>> Hi Daniel, >>>> >>>> On Tue, Aug 25, 2015 at 5:42 PM, Daniel Peebles <[email protected]> >>>> 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 >>>> [email protected] >>>> http://lists.science.uu.nl/mailman/listinfo/nix-dev >> >> > > > > -- > Nicolas Pierron > http://www.linkedin.com/in/nicolasbpierron - http://nbp.name/ > _______________________________________________ > nix-dev mailing list > [email protected] > http://lists.science.uu.nl/mailman/listinfo/nix-dev _______________________________________________ nix-dev mailing list [email protected] http://lists.science.uu.nl/mailman/listinfo/nix-dev
