[Haskell-cafe] 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. Best regards, José -- José António Branquinho de Oliveira Lopes Instituto Superior Técnico Technical University of Lisbon ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] 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 Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] 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) 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 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Cabal dependencies
On 6 October 2012 17:25, José Lopes jose.lo...@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@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] 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 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é ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] 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 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é António Branquinho de Oliveira Lopes Instituto Superior Técnico Technical University of Lisbon ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] 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 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é ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] 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: 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é António Branquinho de Oliveira Lopes Instituto Superior Técnico Technical University of Lisbon ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] 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 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Cabal dependencies
On Thu, 2009-01-15 at 18:38 -0500, Stephen Hicks wrote: Hi, I'm having some difficulty specifying dependencies in my .cabal file for a package I'm looking to upload to hackage soon. The difficulty is as follows. I basically want to specify parsec (= 2.1 3.0.0) || ( 3.0.0 4) When we first introduced this kind of version range syntax we were unsure if it was too general or not. We want to be able to translate into other systems and they're typically more restrictive. Internally we can easily represent the above expression as it uses arbitrary unions and intersections. However the external parser still only allows two clauses (I think it's two). Personally I'm all for lifting that restriction. Yes it makes it a bit harder for translating into some systems but I don't see that as a real issue. If the package really does require the more complex version range then forcing the package author to lie by using a less expressive syntax does not help. We can still make the same choice at the point when we translate into native packages. Also, as it happens there is a way of getting around the restriction anyway, which makes the restriction effectively pointless. That is by listing the same dependency more than once. All the version constraints must be satisfied so you can write: build-depends: parsec = 2.1 4, parsec 3.0.0 || 3.0.0 (have I got that right?) So I'd be interested to get feedback on lifting the restriction and the impact that might have on translation into native packages. The problem is that 3.0.0 as it exists on hackage is missing a constructor that I need (namely, Postfix, in the compatibility module). The bug was fixed and will presumably work fine if a newer version of parsec is ever uploaded to hackage, and my package works fine with older parsecs as well - I just want to exclude this one version. How can I go about doing that? Try the above. A secondary question is this - I can actually compile with version 3.0.0 by just not using this constructor, although it does reduce the package's functionality. I've seen flags in various .cabal files, and presumably I could invent a flag to make it work with 3.0.0, but I'm confused about how these flags are set. Yes, if you need compatibility with older versions of Cabal then you'd need to use a flag. If you're prepared to require Cabal-1.6 or later then you can use the cpp macro: #if MIN_VERSION_parsec(3,0,0) though of course that only gives you = 3.0.0, you'd need more tricky combinations to get == 3.0.0, perhaps by assuming = 3.0.1 is ok. For older Cabal versions the main option is a flag, like so: flag parsec3 ... if flag(parsec3) build-depends: parsec == 3.0.0 cpp-options: -DUSING_BAD_PARSEC else build-depends: parsec 3.0.0 || 3.0.0 Specifically, cabal-install has never asked me anything about flags, so what's the point? Or does it automatically set whichever flags satisfy the dependencies? It tries to work out what flags to set automatically (based on the platform, the available packages and flag defaults in each package). You can override them from the command line if you want to or need to. Duncan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Cabal dependencies
Hi, I'm having some difficulty specifying dependencies in my .cabal file for a package I'm looking to upload to hackage soon. The difficulty is as follows. I basically want to specify parsec (= 2.1 3.0.0) || ( 3.0.0 4) The problem is that 3.0.0 as it exists on hackage is missing a constructor that I need (namely, Postfix, in the compatibility module). The bug was fixed and will presumably work fine if a newer version of parsec is ever uploaded to hackage, and my package works fine with older parsecs as well - I just want to exclude this one version. How can I go about doing that? A secondary question is this - I can actually compile with version 3.0.0 by just not using this constructor, although it does reduce the package's functionality. I've seen flags in various .cabal files, and presumably I could invent a flag to make it work with 3.0.0, but I'm confused about how these flags are set. Specifically, cabal-install has never asked me anything about flags, so what's the point? Or does it automatically set whichever flags satisfy the dependencies? Thanks, steve ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
