
Haskell Packages for Development - lelf
https://wunki.org/posts/2014-05-17-haskell-packages-development.html
======
mlitchard
Greg Weber gave an awesome talk at BayHac 2014 on just this subject.
[https://docs.google.com/presentation/d/1suMuLRo1xS5NxWn-L9lG...](https://docs.google.com/presentation/d/1suMuLRo1xS5NxWn-L9lGHtVNpOH48F9ZnDyv5PyxEpI/edit?pli=1#slide=id.p)

~~~
lomnakkus
Any chance there's a video of that talk?

~~~
jfischoff
The videos for BayHac 2014 have not been (officially) released.

------
taylorfausak
I built a template for hi that sets up stylish-haskell, a test suite, an
executable, and much more. Check it out:
[http://taylor.fausak.me/2014/03/04/haskeleton-a-haskell-
proj...](http://taylor.fausak.me/2014/03/04/haskeleton-a-haskell-project-
skeleton/)

------
moomin
Of course, when I last tried installing stylish-haskell (last week), it
insisted on taking non-compatible/broken dependencies. Yes, on a clean
environment.

When I learn more Haskell, I may succeed to figuring out what's wrong.

~~~
jfischoff
The package management story in Haskell, I don't want to say broken, is just
too complicated for beginners, err actually everyone.

For instance, to install stylish-haskell you will ultimately need the "happy"
executable, but cabal is not smart enough to get it for you.

I don't know what a "clean" environment means, nor do I know what you mean by
"broken dependencies." Did you:

    
    
        mkdir stylish-sandbox
        cd stylish-sandbox
        cabal update 
        cabal sandbox init 
        cabal install happy stylish-haskell 
        cabal copy
        cd ..
        rm -r stylish-sandbox
    

That might work.

~~~
spott
so, what does `cabal copy` do? copy the sandbox to your local .cabal/bin/?

~~~
jfischoff
yeah

~~~
moomin
Doesn't do it. In other news, stylish-haskell appears to have been updated and
now installs. :)

Still, as a first experience of haskell, it ain't great.

------
cordite
It still takes a long time when sandboxing if you're on a project using yesod
and you get to re-build the entire dependency set for each project.

~~~
jfischoff
Sandboxing is merely a stop-gap to reproducible builds (I hope). Nix style
multiple instances of the same version of an installed package will lead to
better reuse, thus faster builds.

If the fingerprints can be made precise enough, binary caches can be
distributed from trusted parties, similar to what other package managers do.

~~~
cordite
Just a thought, why not have fingerprints be like a Merkle tree?

A (naive) example: a built package has the hash derived from the package
identity and all dependency hashes at compile / link time.

~~~
jfischoff
This is the plan I think, or something like it.

Currently package _are_ referred to by unique hash that sort of works this
way, but there are few unfortunate restrictions in GHC and cabal that need to
be lifted to allow future installations to not conflict with past
installations (multiple instances of the same version, right now there can
only be one foo-0.1.0.0 even though it also has a unique hash).

