Howto deal with Cabal dependencies?
Hi guys As you probably know Cabal packages sometimes have some very complicated dependencies including dependencies to older versions of a library or module. What's the best way to deal with this from the perspective of FreeBSD's ports? Can we have different versions of a port in the portstree so that a you can specify a suitable version in the *DEPENDS? I'm working on such a Cabal package at the moment. It has dependencies to an old version of the network and time module, respectively. regards, dave
Hello dave, On 02/03/10 23:03, david fries wrote:
As you probably know Cabal packages sometimes have some very complicated dependencies including dependencies to older versions of a library or module. What's the best way to deal with this from the perspective of FreeBSD's ports? Can we have different versions of a port in the portstree so that a you can specify a suitable version in the *DEPENDS?
The "policy" for FreeBSD Haskell ports is very simple at the moment: no multiple versions, always use the latest available version in the tree, all ports are tuned to the currently supported GHC version (6.10.4). It is not the most elegant approach, but that is what we have now. We have just started to add more ports :)
I'm working on such a Cabal package at the moment. It has dependencies to an old version of the network and time module, respectively.
Which package is that? If you name it, maybe we can help you in working around the problem. I think the distinction between the old and new versions of the network and time modules is to support different GHC versions. GHC 6.10.4 includes network 2.2.1.2 and time 1.1.4 by default, so I would not care about that dependency in the port. Cheers, :g
First of all, I have to say I'm glad this list is not completely dead :)
Which package is that? If you name it, maybe we can help you in working around the problem. I think the distinction between the old and new versions of the network and time modules is to support different GHC versions. GHC 6.10.4 includes network 2.2.1.2 and time 1.1.4 by default, so I would not care about that dependency in the port.
I'm working on a port of Haskell-Platform. I has the following dependencies: GLUT ==2.1.1.2, HTTP ==4000.0.6, OpenGL ==2.2.1.1, cgi ==3001.1.7.1, editline ==0.2.1.0, << I'm struggling with that a bit fgl ==5.4.2.2, network ==2.2.1.4, << I'm going to submit that (version 2.2.1.7) time ==1.1.2.4, << I'm going to submit that (version 1.1.4) zlib ==0.5.0.0 It also has dependencies to Cabal 1.6.x which I've submitted last week together with cabal-install. I'm porting the three remaining modules. All others are already available in the ports. Although some of them are newer versions. The Haskell guys have adopted a versioning policy a while ago (http://www.haskell.org/haskellwiki/Package_versioning_policy) however, not all ports follow it (e.g. HTTP). I'm a bit worried that they won't all work together - especially if the major version doesn't match. P.S. I'm gonna be off for the next three weeks, so don't be surprised if I don't respond during that time.
So. I've been slacking around for the last month not doing much. However the Haskell platform is still on my list of things to do. But I'm kind of stuck here. The version dependencies I listed previously have to be met exactly. This means, of course, that the ports I submitted wouldn't work either. So that was pointless. Well not quite, Jacula and Gabor sent me feedback, which is always welcome. You both pointed out that installing ports which are already part of lang/ghc may cause problems. However I don't see why. Take the network module, for example. The network-2.2.1.2 module comes as part of the ghc port. A potential network-2.2.1.4 port would be installed by itself in /usr/local/lib/network-2.2.1.4 and its haddock documentation is also in a separate directory. ghc-pkg list shows two different installed network versions, but GHC & Cabal have been designed to handle multiple module versions. So I don't see what the problem is. Maybe someone could elaborate on that a little bit more. So that I can come up with an acceptable solution. Frankly, the issue of version dependencies is pretty important to me. The current happy go lucky way of just have the latest version of a module in the portstree is insufficient. I'm sure I'm not the first one to bump into this issue. Right? If I had my way, I would explicitly put the version in the name suffix. On Sun, 2010-02-07 at 16:32 +0100, david fries wrote:
First of all, I have to say I'm glad this list is not completely dead :)
Which package is that? If you name it, maybe we can help you in working around the problem. I think the distinction between the old and new versions of the network and time modules is to support different GHC versions. GHC 6.10.4 includes network 2.2.1.2 and time 1.1.4 by default, so I would not care about that dependency in the port.
I'm working on a port of Haskell-Platform. I has the following dependencies:
GLUT ==2.1.1.2, HTTP ==4000.0.6, OpenGL ==2.2.1.1, cgi ==3001.1.7.1, editline ==0.2.1.0, << I'm struggling with that a bit fgl ==5.4.2.2, network ==2.2.1.4, << I'm going to submit that (version 2.2.1.7) time ==1.1.2.4, << I'm going to submit that (version 1.1.4) zlib ==0.5.0.0
regards, dave
Hey, On 03/09/10 22:22, david fries wrote:
You both pointed out that installing ports which are already part of lang/ghc may cause problems. However I don't see why. Take the network module, for example.
Let me help you then. I installed your port right from the PR [1], and let us assume that I have the following Haskell source (Networking.hs): module Networking where import Data.ByteString.Lazy import Data.Maybe import Network.HTTP import Network.Stream import Network.URI getBinary :: String -> IO ByteString getBinary url = do uri <- return $ fromJust $ parseURI url rsp <- simpleHTTP $ request uri getResponseBody rsp where request uri = Request { rqURI = uri , rqMethod = GET , rqHeaders = [] , rqBody = empty } When I try to compile it (`ghc --make Networking.hs`) I got this: Networking.hs:12:30: Couldn't match expected type `network-2.2.1.2:Network.URI.URI' against inferred type `URI' In the first argument of `request', namely `uri' In the second argument of `($)', namely `request uri' In a stmt of a 'do' expression: rsp <- simpleHTTP $ request uri However, the following thing could help: $ ghc --make Networking.hs -package network-2.2.1.2 But that is a really ugly workaround, I think. For your information, the GHC shipped with Haskell Platform (on Windows, at least) *does not* include network-2.2.1.2, only network-2.2.1.4, so there are no duplicate network packages installed. To achieve the same result with your approach (lang/ghc + "devel/hs-network2214"), we would need to fumble with the files that lang/ghc installed before. Perhaps there could be some option in lang/ghc/Makefile to set whether we want to install GHC as part (actually SLAVE) of Haskell Platform or not, so we can replace the corresponding modules for sake of conformity to the specification. That might be a solution, and it would not even require a separate port or anything else.
A potential network-2.2.1.4 port would be installed by itself in /usr/local/lib/network-2.2.1.4 and its haddock documentation is also in a separate directory.
Well, your PR contains the port of network-2.2.1.7 :P
ghc-pkg list shows two different installed network versions, but GHC & Cabal have been designed to handle multiple module versions.
Can it do that automatically so I was wrong above?
So I don't see what the problem is. Maybe someone could elaborate on that a little bit more. So that I can come up with an acceptable solution.
I hope now you see my concerns. But I described a potential solution.
Frankly, the issue of version dependencies is pretty important to me. The current happy go lucky way of just have the latest version of a module in the portstree is insufficient. I'm sure I'm not the first one to bump into this issue. Right? If I had my way, I would explicitly put the version in the name suffix.
I agree on that, but can you give some examples on when it is better to have not the latest version in the ports tree (other than this HP issue)? A problem could be that the ports tree cannot handle versions so elegantly as Cabal does (as far as I know): there is no way to specify an upper limit for the version of a dependency, i. e. x <= n, but I might be wrong. Hope that helps, :g [1] http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/143649
Yes this cleared things a great deal, thanks! I wanted to write and let you know where I stand at the moment. I've been searching the web and reading lots of mailing list posts and so on. I've also visited the Debian Haskell[1] site to get some info. But I haven't (yet) come up with a workable solution. Indeed, it seems like updating core libraries is a really bad idea(TM) :) While reading the cabal manual, I discovered that you can hide installed packages in with: ghc-pkg hide PACKAGENAME-VERSION. Hidden packages are enclosed in parenthesis in the package list. This way ghc won't see it when trying to compile a program. So you could hide all, but the latest version of an installed library. However, I'm sure that this would be the intended use of that feature I'll keep on searching. regards, dave [1] http://wiki.debian.org/Haskell On Wed, 2010-03-10 at 00:31 +0100, Gabor PALI wrote:
Hey,
On 03/09/10 22:22, david fries wrote:
You both pointed out that installing ports which are already part of lang/ghc may cause problems. However I don't see why. Take the network module, for example.
Let me help you then. I installed your port right from the PR [1], and let us assume that I have the following Haskell source (Networking.hs):
module Networking where
import Data.ByteString.Lazy import Data.Maybe import Network.HTTP import Network.Stream import Network.URI
getBinary :: String -> IO ByteString getBinary url = do uri <- return $ fromJust $ parseURI url rsp <- simpleHTTP $ request uri getResponseBody rsp where request uri = Request { rqURI = uri , rqMethod = GET , rqHeaders = [] , rqBody = empty }
When I try to compile it (`ghc --make Networking.hs`) I got this:
Networking.hs:12:30: Couldn't match expected type `network-2.2.1.2:Network.URI.URI' against inferred type `URI' In the first argument of `request', namely `uri' In the second argument of `($)', namely `request uri' In a stmt of a 'do' expression: rsp <- simpleHTTP $ request uri
However, the following thing could help:
$ ghc --make Networking.hs -package network-2.2.1.2
But that is a really ugly workaround, I think.
For your information, the GHC shipped with Haskell Platform (on Windows, at least) *does not* include network-2.2.1.2, only network-2.2.1.4, so there are no duplicate network packages installed. To achieve the same result with your approach (lang/ghc + "devel/hs-network2214"), we would need to fumble with the files that lang/ghc installed before.
Perhaps there could be some option in lang/ghc/Makefile to set whether we want to install GHC as part (actually SLAVE) of Haskell Platform or not, so we can replace the corresponding modules for sake of conformity to the specification. That might be a solution, and it would not even require a separate port or anything else.
A potential network-2.2.1.4 port would be installed by itself in /usr/local/lib/network-2.2.1.4 and its haddock documentation is also in a separate directory.
Well, your PR contains the port of network-2.2.1.7 :P
ghc-pkg list shows two different installed network versions, but GHC & Cabal have been designed to handle multiple module versions.
Can it do that automatically so I was wrong above?
So I don't see what the problem is. Maybe someone could elaborate on that a little bit more. So that I can come up with an acceptable solution.
I hope now you see my concerns. But I described a potential solution.
Frankly, the issue of version dependencies is pretty important to me. The current happy go lucky way of just have the latest version of a module in the portstree is insufficient. I'm sure I'm not the first one to bump into this issue. Right? If I had my way, I would explicitly put the version in the name suffix.
I agree on that, but can you give some examples on when it is better to have not the latest version in the ports tree (other than this HP issue)?
A problem could be that the ports tree cannot handle versions so elegantly as Cabal does (as far as I know): there is no way to specify an upper limit for the version of a dependency, i. e. x <= n, but I might be wrong.
Hope that helps, :g
participants (2)
-
david fries -
Gabor PALI