[Haskell-cafe] capri cabal-dev virtualenv cab

[Rogan Creswick]

On Tue, Nov 8, 2011 at 1:43 AM, Paul R <paul.r.ml at gmail.com> wrote:
>
> At the moment, my strategy to swap GHC is purely based on the PATH
> environment, and that works well if you don't forget to set this env
> before hacking a project.

This is the best solution I'm currently aware of, but there are ways
we could improve on this (involving new sandboxing tools; similar to
NixOS).

> My strategy for cabal is a bit more
> convoluted, because I had *so many* troubles with multiple databases
> (AKA system db and user db), I decided that everything would go in the
> 'system' one, which is actually just in my user-local GHC install, for
> which my user obviously have required permissions.

I strongly caution against doing this.  My advice is: (explanations below)

 1) /never/ install anything into your system db:
 2) /never/ explicitly install packages that come with ghc (the
packages that are in your system db)
 3) don't rely on your user package db for development -- it's a
convenient place to put things you want to use in ghci, and it's the
simplest thing to use when installing Haskell applications (such as
cabal, cabal-dev, cab, etc...)
 4) use cabal-dev for all development.

Explanations:

(1): Installing to your system package db will prevent you from
sandboxing builds in the context of the Haskell package system.  You
can restrict to individual ghcs, since each ghc has it's own system
db, but you can't prevent your installed package versions from causing
your builds to behave differently than my builds -- as a result, you
may not realize that your package version bounds are broken, for
example.  You'll also not notice when new versions of dependencies
cause your build to break, and you may experience failures when
building other packages because you have a different set of installed
dependencies than the developer expected.

(1 & 2): These things, together, will prevent you from having version
conflicts between the system and user dbs.  Furthermore, cabal-dev
doesn't hide the system db (the tools cabal-dev uses don't expose an
api that enables that in the way that the user db can be hidden, and
the libraries installed in the system db by ghc usually can't be
upgraded/reinstalled without upgrading ghc anyway).

(3) It's impractical to keep your user db clean enough to accomplish
the same objectives of sandboxed builds -- you /can/ do it, but I
don't think it's worth the effort when other tools exist to help
(cabal-dev being my current hammer, capri should also do it, but I
haven't personally had success with capri).

(4) I'm sorry that cabal-dev adds computational overhead -- this
generally isn't an issue when compared to the long-term issues that
come up as a result of dependency resolution /without/ a sandbox, but
I realize that there are situations where cabal-dev can cause build
times to take significantly longer.  Ideas / suggestions / patches /
etc. are happily considered :)

--Rogan

> Things seem to work
> a bit better that way, I guess because cabal has easier time handling
> dependencies.
>
> So far I avoided the project-local database strategy because my system
> does not have much computational power, and I'm bored of waiting for
> ubiquitous packages to compile in all my folders. Arguably, that would
> be the only safe and simple way to avoid clashes, but I'd appreciate
> some shared cache to avoid recompiling the same stuff multiple times. Is
> there some wrappers that can take care of that ?
>
>
> Cheers,
>
> --
>  Paul
>
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>