[Haskell-cafe] Best approach to avoid dependency hells

Rogan Creswick creswick at gmail.com
Wed Dec 5 23:23:07 CET 2012


On Wed, Dec 5, 2012 at 11:13 AM, Jason Dagit <dagitj at gmail.com> wrote:

>
> Let's say you are working in a directory foo that contains a cabal file
> for package foo. When you type 'cabal-dev install', cabal-dev looks at
> foo.cabal in the current directory, it uses it to calculate constraints and
> then installs the dependencies locally that satisfy those constraints. It
> also has an install-deps command if you just want to install the deps but
> not build/install foo. Additionally, if you want to use locally modified
> versions of the dependencies use 'cabal add-source <path to dep>' from the
> foo directory to add your locally modified package to foo's index so that
> subsequent cabal-dev operations can find it and install it.
>

(minor clarity note: I don't believe there is a cabal add-source, but there
is a cabal-dev add-source, which I think Jason meant above)

cabal-dev add-source can cause problems, and it is not always clear what it
does. Since ~cabal-install-0.10.2, it's also not (usually) necessary.

A simpler workflow is to 'cabal-dev install' a list of packages, eg:

$ cabal-dev install <path to dep> <path to dep> <path to foo>

That should run the solver once, finding a global solution, and installing
the required dependencies (and foo) into the local sandbox.  You should
only need this for packages that are not on hackage, or that you've
modified and want to use local versions.

--Rogan


>
> Basically, don't install the deps by hand. Let cabal-dev figure out the
> mutually compatible versions and install that *locally* to where you're
> building foo.
>
> As for the problem of recursively rebuilding the deps, I think 'cab' [1]
> solves this but I haven't tried it.
>
> [1] http://hackage.haskell.org/package/cab
>
>
>
>> I also thought about adding process, bytestring and other global
>> packages to the list of constraints in ~/.cabal/config. Would this be
>> a good approach, or will it lead to bigger headaches in the future
>> (for instance, in the form of programs that just cannot be installed
>> at all)?
>>
>
> Adding these constraints will come back to bite you. That's been my
> experience.
>
>
>>
>> Also, is there any way to detect potential dependency hells without
>> having to install a package? (Some tool that will analyse the
>> dependency information (statically) and determine more strict or
>> incorrect upper and lower bounds for the dependencies of a package.)
>>
>
> --dry-run?
>
> Jason
>
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/haskell-cafe/attachments/20121205/94fa5581/attachment.htm>


More information about the Haskell-Cafe mailing list