Haskell Packages for Development | Hacker News Reader

Haskell Packages for Development

wunki.org

73 pointslelf18 comments

Greg Weber gave an awesome talk at BayHac 2014 on just this subject. https://docs.google.com/presentation/d/1suMuLRo1xS5NxWn-L9lG...

Any chance there's a video of that talk?

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

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...

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.

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.

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

yeah

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.

Don't blame Haskell for it.

On Gentoo with the official 'haskell' overlay it's just a matter of running

    emerge stylish-haskell

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.

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.

Hopefully we can also get real module interfaces[0] in the not-too-distant future so we can at least lessen some of the spurious diamond dependency problems that tend to crop up once in a while.

[0] http://plv.mpi-sws.org/backpack/

I think for modules to help here, the interface would have to not change between versions, useful for ByteString, not so much for Yesod.

As it stands now, cabal's constraint solver will prevent the installation of a package that indirectly depends on two different versions of the same package. This is too bad, because it is not necessarily true the package will fail to install.

Ideally cabal could somehow know which types are exported and which are not. In lieu of that, I personally I would prefer to have a chance of a successful install, and get a compiler error if things really do conflict, instead of a conservative constraint solver error.

Certainly it's not going to be a panacea, but if you are familiar with O'Caml or SML you can hopefully sort of see how it's going to be of immense help when dealing with "trivial" package upgrades and such.

Hopefully Yesod will also (if/when this Backpack thing comes to fruition) expose some sort of stable interface for, say, the 5.x series. I think Michael has been very good about keeping things compatible, given the current constraints on the ecosystem, so I imagine he'd be very interested in declaring a stable interface explicitly if that were possible.

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.

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).

Note that it's not optimal either, a small variation in a root dependency can trigger the recompilation of the whole tree, even if the change is backward-compatible.

Reply on news.ycombinator.com