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
