[Haskell-cafe] Cabal dependencies

[José Lopes]

Hello,

I'm trying to understand Cabal dependencies.
Why does the following situation happen?

# cabal install xmobar --dry-run
Resolving dependencies...
In order, the following would be installed:
parsec-3.1.3 (reinstall) changes: mtl-2.1.1 -> 2.0.1.0
xmobar-0.15 (new package)
Warning: The following packages are likely to be broken by the reinstalls:
texmath-0.6.1.1
regex-tdfa-1.1.8
Unixutils-1.50
network-2.4.0.1
HTTP-4000.2.5
network-2.3.0.14
sendfile-0.7.6
happstack-server-7.0.7
happstack-hsp-7.1.0
happstack-7.0.0
hslogger-1.1.5
citeproc-hs-0.3.4
acid-state-0.6.4
HTTP-4000.2.3
ltk-0.12.1.0
json-0.5
highlighting-kate-0.5.1
Use --force-reinstalls if you want to install anyway.

Best regards,
José

--
José António Branquinho de Oliveira Lopes
Instituto Superior Técnico
Technical University of Lisbon


_______________________________________________
Haskell-Cafe mailing list
Haskel...@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Yuras Shumovich]

On Sat, 2012-10-06 at 17:02 +0200, José Lopes wrote:
> Hello,
Hello

>
> I'm trying to understand Cabal dependencies.
> Why does the following situation happen?

xmobar-0.15 depends on mtl-2.0.* and needs parsec

All packages that will be broken, depends on parsec.
But parsec is compiled with mtl-2.1.1
To install xmobar, cabal needs to reinstall parsec with mtl-2.0.1.0

Thanks,
Yuras

>
> # cabal install xmobar --dry-run
> Resolving dependencies...
> In order, the following would be installed:
> parsec-3.1.3 (reinstall) changes: mtl-2.1.1 -> 2.0.1.0
> xmobar-0.15 (new package)
> Warning: The following packages are likely to be broken by the reinstalls:

> Best regards,
> José

[José Lopes]

OK.

But, wouldn't it be possible for xmobar to use mtl-2.0.1.0 and for
parsec to use mtl-2.1.1, while xmobar would use this parsec version?
In this case, I am assuming that mtl-2.0.1.0 and mtl-2.1.1 are
considered two different libraries.

Thanks,
José

On 06-10-2012 17:17, Yuras Shumovich wrote:
> On Sat, 2012-10-06 at 17:02 +0200, José Lopes wrote:
>> Hello,
> Hello
>> I'm trying to understand Cabal dependencies.
>> Why does the following situation happen?
> xmobar-0.15 depends on mtl-2.0.* and needs parsec
>
> All packages that will be broken, depends on parsec.
> But parsec is compiled with mtl-2.1.1
> To install xmobar, cabal needs to reinstall parsec with mtl-2.0.1.0
>
> Thanks,
> Yuras
>
>> # cabal install xmobar --dry-run
>> Resolving dependencies...
>> In order, the following would be installed:
>> parsec-3.1.3 (reinstall) changes: mtl-2.1.1 -> 2.0.1.0
>> xmobar-0.15 (new package)
>> Warning: The following packages are likely to be broken by the reinstalls:
>> Best regards,
>> José
>>
>

--
José António Branquinho de Oliveira Lopes
Instituto Superior Técnico
Technical University of Lisbon

[Duncan Coutts]

On 6 October 2012 17:25, José Lopes <jose....@ist.utl.pt> wrote:
> OK.
>
> But, wouldn't it be possible for xmobar to use mtl-2.0.1.0 and for parsec to
> use mtl-2.1.1, while xmobar would use this parsec version?
> In this case, I am assuming that mtl-2.0.1.0 and mtl-2.1.1 are considered
> two different libraries.

Possibly, yes, but cabal doesn't know that. It has to make the
conservative assumption that you might use them together and so they'd
better be the same type.

If cabal knew for sure that parsec did not expose types from mtl, then
it'd be fine for it to use parsec built against a different version of
mtl, because there would be no way to end up trying to equate types
from two different package instances.

This is the idea behind private or encapsulated dependencies: we would
declare in .cabal files that our use of some dependency does not "leak
out". But to be clear: this feature has not yet been implemented.

But actually in this case I think parsec does expose the fact that it
uses types from mtl. So it actually would not help here.

Duncan

[Yuras Shumovich]

On Sat, 2012-10-06 at 18:25 +0200, José Lopes wrote:
> OK.
>
> But, wouldn't it be possible for xmobar to use mtl-2.0.1.0 and for
> parsec to use mtl-2.1.1, while xmobar would use this parsec version?
> In this case, I am assuming that mtl-2.0.1.0 and mtl-2.1.1 are
> considered two different libraries.

Usually it leads to "strange" compilation errors.

E.g.
Package A:
data AA = AA String
func0 :: Int -> AA
func0 n = AA $ replicate n "A"
func1 :: AA -> Int
func1 (AA str) = length str

Package B:
import A
func2 :: AA -> Int
func2 aa = func1 + 1

Package C:

import A
import B
func3 :: Int -> Int
func3 n = func2 $ func0 n

If C and B are compiled with different versions of C,
then func3 will not compile. Compiler will say that
AA returned by func0 doesn't match AA expected by func2

More real examples:
http://stackoverflow.com/questions/11068272/acid-state-monadstate-instance-for-update
http://stackoverflow.com/questions/12576817/couldnt-match-expected-type-with-actual-type-error-when-using-codec-bmp/12577025#12577025

>
> Thanks,
> José

[José Lopes]

OK. Got it!

Do you have any suggestions to install xmobar in this particular case?

Thanks,
José

--

José António Branquinho de Oliveira Lopes
Instituto Superior Técnico
Technical University of Lisbon

[Yuras Shumovich]

On Sat, 2012-10-06 at 22:40 +0200, José Lopes wrote:
> OK. Got it!
>
> Do you have any suggestions to install xmobar in this particular case?

In case of executables I usually rm -rf ~/.ghc, cabal install,
and rm -rf ~/.ghc again. Executables are still here (in ~/.cabal/bin),
but all libraries are lost. Warning: it may break your development
environment, so make sure you know what you are doing.

Better solution could be sandbox tools like cabal-dev. They alloy you to
setup development environment per project.

_______________________________________________

[José Lopes]

Thanks!

--
José António Branquinho de Oliveira Lopes
Instituto Superior Técnico
Technical University of Lisbon

[Andres Löh]

>>> Do you have any suggestions to install xmobar in this particular case?
>>
>> In case of executables I usually rm -rf ~/.ghc, cabal install,
>> and rm -rf ~/.ghc again. Executables are still here (in ~/.cabal/bin),
>> but all libraries are lost. Warning: it may break your development
>> environment, so make sure you know what you are doing.
>>
>> Better solution could be sandbox tools like cabal-dev. They alloy you to
>> setup development environment per project.

In this particular case, removing all libraries is total overkill.
That should be reserved for situations where the package DB is already
broken, but afaiu, this has not happened here yet.

I'm quite convinced xmobar-0.15 actually works with the more recent mtl. So
you can try:

$ cabal unpack xmobar
$ cd xmobar-0.15

edit the xmobar.cabal file and remove the upper bound from mtl

$ cabal install

Cheers,
Andres