Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Haskell Packages for Development

wunki.org

Post reply on HN
Print view View original

11–20 of 20 posts

Re: Haskell Packages for Development

#11

Post by jfischoff »

lomnakkus wrote: post #10
jfischoff wrote: post #8

Earlier quoted context omitted.

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.

Re: Haskell Packages for Development

#12

Post by cordite »

jfischoff wrote: post #8
cordite wrote: post #6

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.

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.

Re: Haskell Packages for Development

#13

Post by jfischoff »

cordite wrote: post #12
jfischoff wrote: post #8

Earlier quoted context omitted.

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.

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

Re: Haskell Packages for Development

#14

Post by spott »

jfischoff wrote: post #5
moomin wrote: post #4

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…

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

Re: Haskell Packages for Development

#15

Post by lomnakkus »

jfischoff wrote: post #11
lomnakkus wrote: post #10

Earlier quoted context omitted.

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…

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.

Re: Haskell Packages for Development

#16

Post by jfischoff »

spott wrote: post #14
jfischoff wrote: post #5

Earlier quoted context omitted.

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…

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

yeah

Re: Haskell Packages for Development

#18

Post by zimbatm »

cordite wrote: post #12
jfischoff wrote: post #8

Earlier quoted context omitted.

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.

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.

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.

Re: Haskell Packages for Development

#19

Post by stefantalpalaru »

moomin wrote: post #4

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.

Don't blame Haskell for it.

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

    emerge stylish-haskell

Re: Haskell Packages for Development

#20

Post by moomin »

jfischoff wrote: post #16
spott wrote: post #14

Earlier quoted context omitted.

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.

Post reply on HN