Good work! How many machines did it take to pull this off?
On Sun, Jun 12, 2016 at 7:24 PM, Peter Simons wrote:
> Fellow Haskell Hackers,
>
> Nixpkgs 'master' now has the entire Hackage database available:
>
>
> https://github.com/NixOS/nixpkgs/commit/2862d272a606c6188c4c33dab60de4e0066ee194
>
>
Fellow Haskell Hackers,
Nixpkgs 'master' now has the entire Hackage database available:
https://github.com/NixOS/nixpkgs/commit/2862d272a606c6188c4c33dab60de4e0066ee194
No more running cabal2nix manually. :-)
There is more work to come, i.e. cleaning up and refactoring, but in
principle the
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/
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
On Fri, Nov 20, 2015 at 1:58 PM Shea Levy 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
On Fri, Nov 20, 2015 at 1:51 PM Daniel Peebles wrote:
> The downside of this approach is that generating the entire Haskell
>> package set is actually kind of expensive, and we probably wouldn't want
>> to impose those costs onto random users who just wants to have XMonad
>> for their window mana
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 t
>
> The downside of this approach is that generating the entire Haskell
> package set is actually kind of expensive, and we probably wouldn't want
> to impose those costs onto random users who just wants to have XMonad
> for their window manager
>
Couldn't the derivation we're importing from be ca
Hi Oliver,
> [You really want to commit] the scripts that *generate* the 50mb file
> as some sort of Nix expression. Then, when I as a user choose to
> evaluate the set of Haskell packages, I will be forced to generate
> all the Nix expressions - or, this being Nix, ask a binary
> substitutio
On Thu, Nov 19, 2015 at 11:14 AM Peter Simons wrote:
> One issue is that checking that ~50MB file into Nixpkgs might be a bad
> idea, because it sets a dangerous precedent. Arguably, if we check all
> of Hackage into Nixpkgs, then we cannot reasonably say *no* to someone
> who wants to check all
Are haskell libraries useful other than at compile time ?
Nix doesn't do dependency resolution in regards to version matching and I
don't think that we will ever have a unified hackage where all the latest
versions work together. Tools like cabal2nix seem essential in that regard.
If we where to
The Problem
---
Users of Nixpkgs want to build Haskell packages that have no recent
release, i.e. the software's authors have not updated their code to deal
with modern versions of the respective build dependencies. The required
old versions, however, may not be available in Nixpkgs, and t
12 matches
Mail list logo