[Nix-dev] Haskell NG

[Shea Levy]

> On Dec 12, 2014, at 11:19 PM, Marc Weber <marco-oweber at gmx.de> wrote:
> 
>> - hackage-packages.nix is generated automatically by the "hackage2nix" utility
>>   from the "v2.x" branch of the cabal2nix repository [2]. The file defines
>>   builds for the respective latest version of every Hackage package.
>>   hackage2nix can include some older package versions, too, if necessary.
> So does the spirit behind hack-nix win finally? Finally? :)
> 

I don’t think Peter intends to generate the package set at evaluation time, a static file will be committed.

> If we "rewrite" the stuff we should get it right this time.
> I feel getting this right means
> 1) versioning hackage
> 2) implement a way to retrieve hackage packages (either by api or from
>  versioned hackage dump)
> 3) share package resolution with cabal (don't invent our own stuff -
>  because it will always be a lot of work and be totally different)
> 
> AFAIK Shea has added a way to load .dll functions. I think I remember it
> is possible to call Haskell from C code. Thus what about collaborating
> on the implementation sketched above?
> 

I don’t think builtins.importNative or nix-exec should be used as part of nixpkgs. Installing a package should not be able to execute arbitrary code as your user.

> It would serve as "sample" which could be adopted for the other
> universes (perl/python/ruby/java/scala/rust/vim/emacs/whatever).
> 
> 
> Thus how could usage look like?
> 
> haskellPackages {
>  hackage-dbs: [
>    "http://some-mirror/version/2014-12-10-hackage-packages.tar.gz")
>    "my custom stuff"
>  ]
>  resolve: "bytestring"
> }
> 
> Due to referencing a hackage like database by date it should be
> deterministic.
> Fetching all versions of a package could be done by API (HTTP) or such -
> thus downloading hackage would no longer be necessary.
> 
> Thoughts?
> 
> This is the next thing I'd try trying to learn from hack-nix.
> For all of you who don't know what hack-nix is: Its a brute for
> dependency solver written in Nix reading a hackage database which was
> serialized to a .nix file doing exactly what Peter wants to implement:
> Latest versions + some manually added older versions to make packages
> resolve. Additionally its easy to add your own packages (eg dev
> versions) and call the solver as well as patch packages (eg .cabal
> files, especially its dependency information) before turning it into a
> huge .nix file.
> 
> You can find a short description  https://nixos.org/wiki/Nixpkgs-haskell-overlay
> 
> It was meant to be a proof of concept. Now I'd like to ask you whether
> you would prefer joining a common effort which is most likely to work.
> 
> Its too painful to role my own solutions for everything (haskell, ruby
> overlay etc - even though it often works nicely - and fails due to lack
> of man power).
> 
> Peter: Please comment on the proposal, I'd rather join than keeping my
> own stuff, but your attempt just seems to be another "hack-nix" with all
> of its problems.
> 
> Who would join implementing the design I've sketched above?
> 
> Live is too short IMHO. My point of view might be limited - thus if I
> make any bad assumptions please tell me.
> 
> Marc Weber
> _______________________________________________
> nix-dev mailing list
> nix-dev at lists.science.uu.nl
> http://lists.science.uu.nl/mailman/listinfo/nix-dev