[Nix-dev] Publish All of Hackage

[Roger Qiu]

Having an immutable content addressable storage for packages will really
help maintain legacy applications. I got bitten recently by NPM wiping out
a package completely which was a deep dependency of a number of legacy
dependencies. Some software just doesn't need to be updated for years.
On 01/12/2015 3:14 PM, "Ericson, John" <john_ericson at brown.edu> wrote:

> Yeah longer term https://github.com/NixOS/nix/issues/520 can be of use,
> but for now normal fetchgit should be fine for the reasons Oliver mentions.
> 52 megs is something, but its only a compile-time dep, and in quite long
> term I hope things like IPFS means the hashes can be checked out
> incrementally.
>
> > Honestly, though, IMO the nix/nixpkgs model of "determine the build
> exactly from the expressions" simply does not match the modern
> language-specific package manager model of "dynamically query a web service
> for the latest versions that meet my constraints". I think something
> leveraging nix-exec [2] might be a good short-term solution, and in the
> long term better management of impurities (at the expression level,
> resulting in still-pure *builds*) is needed.
>
> That incongruity is real, but the things like Stack, and Rust's Cargo's
> and Ruby's bundler's lockfiles convince me that perhaps those tools are a
> bit too non-deterministic for even more mainstream tastes. Not quite sure
> what the optimal setup looks like but I trust we will get there.
>
> Lastly, I mailed list before about this
> https://www.mail-archive.com/nix-dev@lists.science.uu.nl/msg17048.html
> The big points are all already in this thread, but a few ideas on the
> details there.
>
> On Fri, Nov 20, 2015 at 6:42 AM, Oliver Charles <ollie at ocharles.org.uk>
> wrote:
>
>> On Fri, Nov 20, 2015 at 1:58 PM Shea Levy <shea at shealevy.com> wrote:
>>
>>> The problem with doing this with import-from-derivation is we still
>>> need the hashes of every tarball ahead of time (though that's much
>>> smaller than all of hackage, and we really just need the hash of the
>>> file that contains all the hashes in nixpkgs itself). If we have that,
>>> then we don't need to generate all of hackage every time, just the bits
>>> needed to build the specific requested package.
>>>
>>
>> What I would expect is that the "generate Nix expressions" Nix expression
>> - i.e., the thing that generates what is now hackage-packages.nix - would
>> have to be given known inputs. As far as I understand, hackage2nix simply
>> requires a checkouts of
>> https://github.com/commercialhaskell/all-cabal-hashes and
>> https://github.com/commercialhaskell/all-cabal-hashes. I would expect
>> that those could be provided by fetchgit, so updating the set of Haskell
>> packages simply requires Peter or other commiters to change the pinned Git
>> revisions.
>>
>> _______________________________________________
>> 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/20151201/bdb20b58/attachment.html