I haven't entirely followed this and I see that it's been split over multiple threads.
Did "cabal install random" actually fail for you under ghc-7.4.0.20111219? If so I'd love to know about it as the maintainer of the "random" package. (It seems to work for me for random-1.0.1.1.) That said, I'm sure AC-random is a fine alternative, and there are many other packages on Hackage as well, including cryptographic strength ones (crypto-api, intel-aes, etc). Cheers, -Ryan On Sun, Jan 1, 2012 at 7:11 AM, Yitzchak Gale <g...@sefer.org> wrote: > I wrote: >>> Today, it is very unusual to use GHC by itself. >>> To use Haskell, you install the Haskell Platform. >>> That is GHC together with Cabal and a basic >>> set of libraries. It is very easy to install. > > Wolfram Kahl wrote: >> However, since you are willing and able to test bleeding-edge versions of >> GHC, >> you need to be able to live without the platform, which typically >> catches up to GHC versions only within a couple of months. > > It's true that the platform provides a stable version of GHC, > as needed by most people, not the bleeding edge. But even if you need > GHC HEAD you would typically use cabal. Unless for some reason > you need to shuffle around manually the various pieces that get built, > follow trees > of package dependencies manually, etc. There are some people > who need to do it, and it is doable, though much more > complicated and error-prone than just using cabal. > >>> Almost all Haskell software is expected to >>> be installed using Cabal nowadays. > >> It is important to know that people associate two packages >> with the name ``Cabal'' > > They are closely interconnected though. If you use the platform, > that distinction is not very important. It just works. > >> Life without cabal-install is not only possible, >> but also safer. > > I disagree with that. Manual processes are error-prone. > > With experience, you can learn how > to do things totally manually, just like you can learn to > build C projects manually without make, and with even > more experience, you can learn to avoid all of the > pitfalls. It's a good thing to know, but I wouldn't put > it at first priority unless there's a special reason for it. > >> (See also: http://www.vex.net/~trebla/haskell/sicp.xhtml ) > > The Cabal system is quite mature now, but still far > from perfect. Problems can arise. Most of the problems > are inherent to the "DLL Hell" that can occur in any > separate compilation system, and some arise from the fact > that Cabal's dependency solver needs improvement (that's > a hard problem). > > That link is a detailed write-up of just about everything > that can possibly go wrong. In my experience, none of that > happens until you've been using an installation for a long time, > or if you are very trigger-happy with upgrading packages to the latest > version for no reason. Or if you're using a package with a huge amount > of fast-changing dependencies, like one of the web frameworks. > > Even then, it's almost always easy enough just to re-install the > platform to get a fresh install. Your next few compiles will take a > few minutes longer as some packages get rebuilt, but that's about it. > > To avoid that altogether, I use cabal-dev. This allows me to > build a package I am working on in a sandbox with just the > dependencies it needs, tailored exactly for the needs > of my specific package. Cabal-dev also makes it > easy to experiment with how users will experience > building my package. > > It's good to know all the intricacies of the build system, > and what is happening beneath the surface if it gets > lost. The linked article is a worthwhile read for that. > > Regards, > Yitz > > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users@haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users _______________________________________________ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
