ghc-cabal-Random

[Ryan Newton]

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 <gale at 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 at haskell.org
> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users