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
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é
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
On 6 October 2012 17:25, 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.
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
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-f... http://stackoverflow.com/questions/12576817/couldnt-match-expected-type-with...
Thanks, José
OK. Got it! Do you have any suggestions to install xmobar in this particular case? Thanks, José On 06-10-2012 19:08, Yuras Shumovich wrote:
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-f... http://stackoverflow.com/questions/12576817/couldnt-match-expected-type-with...
Thanks, José
-- José António Branquinho de Oliveira Lopes Instituto Superior Técnico Technical University of Lisbon
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.
Thanks, José
On 06-10-2012 19:08, Yuras Shumovich wrote:
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-f... http://stackoverflow.com/questions/12576817/couldnt-match-expected-type-with...
Thanks, José
Thanks! On 06-10-2012 23:07, Yuras Shumovich wrote:
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.
Thanks, José
On 06-10-2012 19:08, Yuras Shumovich wrote:
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-f... http://stackoverflow.com/questions/12576817/couldnt-match-expected-type-with...
Thanks, José
-- José António Branquinho de Oliveira Lopes Instituto Superior Técnico Technical University of Lisbon
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
participants (4)
-
Andres Löh -
Duncan Coutts -
José Lopes -
Yuras Shumovich