> - 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? :)
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?
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@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev
