headers
José Lopes | 6 Oct 2012 17:02
Picon
Favicon

Cabal dependencies

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.
(Continue reading)

Permalink | Reply |
headers
Yuras Shumovich | 6 Oct 2012 17:17
Picon
Gravatar

Re: Cabal dependencies

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é
> 

_______________________________________________
Haskell-Cafe mailing list
(Continue reading)

Permalink | Reply |
headers
José Lopes | 6 Oct 2012 18:25
Picon
Favicon

Re: Cabal dependencies

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)
(Continue reading)

Permalink | Reply |
headers
Duncan Coutts | 6 Oct 2012 19:06

Re: Cabal dependencies

On 6 October 2012 17:25, José Lopes <jose.lopes <at> 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

_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe <at> haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
(Continue reading)

Permalink | Reply |
headers
Yuras Shumovich | 6 Oct 2012 19:08
Picon
Gravatar

Re: Cabal dependencies

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
(Continue reading)

Permalink | Reply |
headers
José Lopes | 6 Oct 2012 22:40
Picon
Favicon

Re: Cabal dependencies

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
>
(Continue reading)

Permalink | Reply |
headers
Yuras Shumovich | 6 Oct 2012 23:07
Picon
Gravatar

Re: Cabal dependencies

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
(Continue reading)

Permalink | Reply |
headers
José Lopes | 6 Oct 2012 23:10
Picon
Favicon

Re: Cabal dependencies

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:
(Continue reading)

Permalink | Reply |
headers
Andres Löh | 6 Oct 2012 23:22
Picon

Re: Cabal dependencies

>>> 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
Permalink | Reply |

Gmane