[Nix-dev] haskell structure for all of nixpkgs

[zimbatm]

fetchurl is capable of network access and also do computation. If there is
a fixed point in the package index then we can automatically derive the nix
expression as a result. As an example of how it would look like:

    index = fetchopam { version = "2016-04-27"; sha256 = "..."; };
    opam = import index { };

Alternatively we could also host the generated package indexes separately.
It means a bit more work because you have to update the package index repo
and then the hash in nixpkgs.

   haskellPackagesSrc = fetchFromGitHub { owner = "nixos"; repo =
"haskell-packages"; rev = "..."; sha256 = "..."; };
   haskellPackages = import haskellPackagesSrc {};


On Wed, 27 Apr 2016 at 11:49 Thomas Hunger <tehunger at gmail.com> wrote:

> > You are right, the „multiple releases“ approach clogs the repository. In
> general it would be a lot more favourable if we didn’t have to check in
> these thousands of package descriptions but could generate them from
> hackage
>
> IMO an advantage of checking package metadata into git is that we notice
> upstream changes. E.g. GitHub used to re-package their zips all the time
> causing hash changes which we noticed.
>
> In the case of GitHub this was annoying (they fixed it) but in the more
> general case I find the additional hash check very useful because it's one
> less thing I have to worry about.
>
> Not sure how to fix the nixpkgs repository size though if we check in
> hundreds of MB of package metadata.
>
>
> On 27 April 2016 at 10:59, Profpatsch <mail at profpatsch.de> wrote:
>
>> On 16-04-25 03:15pm, Eric Merritt wrote:
>> > I think these strongly win out, at at least for the Erlang/Beam world.
>> The downside is that grepping the
>> > nixpkgs repository (my default way to search for a package) doesn't
>> work nearly as well.
>>
>> You are right, the „multiple releases“ approach clogs the repository.
>> In general it would be a lot more favourable if we didn’t have to check
>> in these thousands of package descriptions but could generate them
>> from hackage (or stackage) description files (aka don’t check in
>> generated files).
>> Has the drawback, that it is not locally possible to see what’s available
>> without a generation step first. Generating nixexprs and then using them
>> is still an unsolved problem, since it puts realizations inside the
>> evaluation
>> phase, see https://github.com/NixOS/nix/issues/13 (notice the issue
>> number).
>>
>> Apart from that the gist of the Haskell infrastructure is how it handles
>> overriding, which is entirely unrelated to the grepping issue.
>>
>> > My suspicion is that, if you wanted to go this route generally, you
>> would need to improve the tooling
>> > around searching for packages/expressions.
>>
>> There’s already nix-repl. Improve that one step further and you can have
>> dynamic exploration, maybe with a search and editor completion.
>>
>>
>> --
>> Proudly written in Mutt with Vim on NixOS.
>> Q: Why is this email five sentences or less?
>> A: http://five.sentenc.es
>> May take up to five days to read your message. If it’s urgent, call me.
>> _______________________________________________
>> nix-dev mailing list
>> nix-dev at lists.science.uu.nl
>> http://lists.science.uu.nl/mailman/listinfo/nix-dev
>>
>
> _______________________________________________
> 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/20160427/cd71b0a8/attachment.html