cabal install HaXml installs wrong version unless I specify the version number
I was upgrading happstutorial.com to ghc 6.10.1 when I came across a cabal install issue. Somewhere in day 1 (probably as a HAppS dependency), HaXml 1.13.1 got installed. On day 2, I wanted the latest version of HaXml (1.19.4), a dependency for for xml-parsec. cabal install HaXml gave me: already installed. cabal upgrade HaXml gave me: some installing action, but in the end I wound up with 1.13.1 again. cabal install HaXml-1.19.4 gave me what I want, the latest version. But even then, when I do cabal install xml-parsec I get Text/ParserCombinators/Parsec/XML.hs:18:7: Could not find module `Text.XML.HaXml.Posn': it is a member of package HaXml-1.19.4, which is hidden The cabal file has Build-Depends: base, parsec, HaXml
ghc-pkg latest HaXml says HaXml-1.19.4
Even after ghc-pkg hide HaXml-1.13.3 I get the same result, so I'm not even sure if the problems I'm having are a result of the having two versions of the same package installed. This is a bug right? Any advice on how to get xml-parsec installed? thomas.
When I specify
Build-Depends: base, parsec, HaXml >= 1.19.4
in xml-parsec.cabal
it does install correctly.
I guess what happens is that cabal install takes the earliest version
of a package registered to try to build. I guess that's a reasonable
default.
What seems unreasonable to me is that cabal continued to take the
earlier version even after I hid it with ghc-pkg hide.
My advice would be to improve the error message to read
"... Could not find module `Text.XML.HaXml.Posn':
it is a member of package HaXml-1.19.4, which is hidden
It can be unhidden by adding
Build-Depends: HaXml >= 1.19.4
to xml-parsec.cabal"
That leaves the issue of cabal upgrade not upgrading to the latest
version available on hackage, which still feels like a real bug to me.
Best, Thomas.
2008/11/15 Thomas Hartman
I was upgrading happstutorial.com to ghc 6.10.1 when I came across a cabal install issue.
Somewhere in day 1 (probably as a HAppS dependency), HaXml 1.13.1 got installed.
On day 2, I wanted the latest version of HaXml (1.19.4), a dependency for for xml-parsec.
cabal install HaXml gave me: already installed. cabal upgrade HaXml gave me: some installing action, but in the end I wound up with 1.13.1 again.
cabal install HaXml-1.19.4 gave me what I want, the latest version.
But even then, when I do cabal install xml-parsec I get
Text/ParserCombinators/Parsec/XML.hs:18:7: Could not find module `Text.XML.HaXml.Posn': it is a member of package HaXml-1.19.4, which is hidden
The cabal file has
Build-Depends: base, parsec, HaXml
ghc-pkg latest HaXml says HaXml-1.19.4
Even after ghc-pkg hide HaXml-1.13.3
I get the same result, so I'm not even sure if the problems I'm having are a result of the having two versions of the same package installed.
This is a bug right?
Any advice on how to get xml-parsec installed?
thomas.
On Sat, 2008-11-15 at 12:39 +0100, Thomas Hartman wrote:
When I specify
Build-Depends: base, parsec, HaXml >= 1.19.4
in xml-parsec.cabal
it does install correctly.
Yes, saying what version it needs is a good thing. It's all guesses otherwise.
I guess what happens is that cabal install takes the earliest version of a package registered to try to build. I guess that's a reasonable default.
Actually it does that for specific packages, there's a file in the hackage index called 'referred-versions': base < 4 parsec < 3 HaXml == 1.13.* QuickCheck < 2 These are all cases where there are large numbers of packages that fail to specify an upper version constraint but break when built with the later version of the package. In the case of HaXml it is also because the 1.13 series is the one considered stable by its author.
What seems unreasonable to me is that cabal continued to take the earlier version even after I hid it with ghc-pkg hide.
We cannot in general consider the hidden status of packages or we'd never be able to use packages like 'ghc' which are always hidden. Perhaps they could be used as soft preferences. If so should those come before or after the preferences from the command line or from the hackage index?
My advice would be to improve the error message to read
"... Could not find module `Text.XML.HaXml.Posn': it is a member of package HaXml-1.19.4, which is hidden It can be unhidden by adding
Build-Depends: HaXml >= 1.19.4
to xml-parsec.cabal"
Unfortunately we cannot easily do that. It is ghc that produces the message about hidden packages but it is cabal that told ghc to hide all the packages (other than those specified in the .cabal file). Some people suggest that we should try parsing the ghc error messages to be able to provide such hints but I don't think that's sensible.
That leaves the issue of cabal upgrade not upgrading to the latest version available on hackage, which still feels like a real bug to me.
That's again down to the preferred versions in the hackage index. It only comes into effect when you specify no version when asking for a package. If you cabal install 'haxml >= 1.14' then it'll pick the latest version. When you "cabal install haxml", do you mean "install the default version" or "install the latest experimental version"? Currently it means the former. If there is general agreement it should mean the latter then we can switch it. Or perhaps it just needs an informational message to tell the user whenever the default version is not the latest version. cabal install haxml Downloading HaXml-1.13.3... Note: the recommended version is HaXml-1.13.3 but latest version is HaXml-1.19, use cabal install haxml-1.19 if you want that version. Or something like that. Duncan
This is all news to me, and un-googleable to boot: http://www.google.pl/search?hl=en&sa=X&oi=spell&resnum=0&ct=result&cd=1&q=cabal+referred-versions&spell=1 (no results) So yes, I think this referred-versions machinery should at least be made more transparent for situations when it does the wrong thing, like with xml-parsec. I think your last suggestion is good
cabal install haxml Downloading HaXml-1.13.3... Note: the recommended version is HaXml-1.13.3 but latest version is HaXml-1.19, use cabal install haxml-1.19 if you want that version.
I would have this message pop up for both cabal install and cabal
upgrade -- especiallly since with cabal upgrade the result was for me
completely bafflling.
Thomas.
2008/11/15 Duncan Coutts
On Sat, 2008-11-15 at 12:39 +0100, Thomas Hartman wrote:
When I specify
Build-Depends: base, parsec, HaXml >= 1.19.4
in xml-parsec.cabal
it does install correctly.
Yes, saying what version it needs is a good thing. It's all guesses otherwise.
I guess what happens is that cabal install takes the earliest version of a package registered to try to build. I guess that's a reasonable default.
Actually it does that for specific packages, there's a file in the hackage index called 'referred-versions':
base < 4 parsec < 3 HaXml == 1.13.* QuickCheck < 2
These are all cases where there are large numbers of packages that fail to specify an upper version constraint but break when built with the later version of the package. In the case of HaXml it is also because the 1.13 series is the one considered stable by its author.
What seems unreasonable to me is that cabal continued to take the earlier version even after I hid it with ghc-pkg hide.
We cannot in general consider the hidden status of packages or we'd never be able to use packages like 'ghc' which are always hidden. Perhaps they could be used as soft preferences. If so should those come before or after the preferences from the command line or from the hackage index?
My advice would be to improve the error message to read
"... Could not find module `Text.XML.HaXml.Posn': it is a member of package HaXml-1.19.4, which is hidden It can be unhidden by adding
Build-Depends: HaXml >= 1.19.4
to xml-parsec.cabal"
Unfortunately we cannot easily do that. It is ghc that produces the message about hidden packages but it is cabal that told ghc to hide all the packages (other than those specified in the .cabal file). Some people suggest that we should try parsing the ghc error messages to be able to provide such hints but I don't think that's sensible.
That leaves the issue of cabal upgrade not upgrading to the latest version available on hackage, which still feels like a real bug to me.
That's again down to the preferred versions in the hackage index. It only comes into effect when you specify no version when asking for a package. If you cabal install 'haxml >= 1.14' then it'll pick the latest version.
When you "cabal install haxml", do you mean "install the default version" or "install the latest experimental version"? Currently it means the former. If there is general agreement it should mean the latter then we can switch it.
Or perhaps it just needs an informational message to tell the user whenever the default version is not the latest version.
cabal install haxml Downloading HaXml-1.13.3... Note: the recommended version is HaXml-1.13.3 but latest version is HaXml-1.19, use cabal install haxml-1.19 if you want that version.
Or something like that.
Duncan
On Sat, 2008-11-15 at 13:31 +0100, Thomas Hartman wrote:
This is all news to me, and un-googleable to boot:
(no results)
It finds something for me (with the right spelling of preferred), eg this thread from the libraries list: http://archive.netbsd.se/?ml=haskell-libraries&a=2008-10&t=8748731
So yes, I think this referred-versions machinery should at least be made more transparent for situations when it does the wrong thing, like with xml-parsec.
Sure, though it is worth remembering that doing the right thing for xml-parsec is completely a guessing game since the package does not say which version it needs and yet works with some versions and not others. That is the root of this problem. We should be thinking about ways to persuade package authors (or others) to supply the correct information. That's where the package versioning policy comes in.
I think your last suggestion is good
cabal install haxml Downloading HaXml-1.13.3... Note: the recommended version is HaXml-1.13.3 but latest version is HaXml-1.19, use cabal install haxml-1.19 if you want that version.
I would have this message pop up for both cabal install and cabal upgrade -- especiallly since with cabal upgrade the result was for me completely bafflling.
Ok, so that we do not forget this, would you mind filing a ticket to explain the confusion and the suggested solution. Linking to this thread would also help. http://hackage.haskell.org/trac/hackage/ Duncan
I have run into another issue with cabal packaging, which seems
related to the issues discussed above. (see attached tar file for
complete example of failure scenario)
If I have a cabal package that depends on two other packages
-- package xml-parsec requires HaXml == 1.19.4 (the latest)
-- package HAppS-Server requires HaXml == 1.13.3 (the default)
ghc --make testDepConflict.hs
works fine.
But I can't install via cabal without, I guess, breaking out the
conflict into a separate cabal package.
Build-Depends: HAppS-Server, xml-parsec, HaXml
-- (Uses HaXml 1.13.3, the default HaXml if no version number is specified)
-- Cabal says:
---- Could not find module `Text.XML.HaXml.Posn':
---- it is a member of package HaXml-1.19.4, which is hidden
-- I say:
---- Ok, I understand why this doesn't work.
Build-Depends: HAppS-Server xml-parsec, HaXml == 1.19.4
-- Cabal says:
---- cabal: dependencies conflict: HAppS-Server requires HaXml ==1.13.3 however
---- HaXml-1.13.3 was excluded because CabalDepConflict-0.1 requires
HaXml ==1.19.4
-- I say:
---- Since HAppS-Server is its own separate package, why is this a conflict?
---- Shouldn't this work?
The workaround is to put the bits of the current package that depend
on HaXml 1.19.4 into their own separate package,
which doesn't require HAppS-Server.
But shouldn't it be possible for cabal to figure out how to install
the package without doing this?
2008/11/15 Duncan Coutts
On Sat, 2008-11-15 at 13:31 +0100, Thomas Hartman wrote:
This is all news to me, and un-googleable to boot:
(no results)
It finds something for me (with the right spelling of preferred), eg this thread from the libraries list:
http://archive.netbsd.se/?ml=haskell-libraries&a=2008-10&t=8748731
So yes, I think this referred-versions machinery should at least be made more transparent for situations when it does the wrong thing, like with xml-parsec.
Sure, though it is worth remembering that doing the right thing for xml-parsec is completely a guessing game since the package does not say which version it needs and yet works with some versions and not others. That is the root of this problem. We should be thinking about ways to persuade package authors (or others) to supply the correct information.
That's where the package versioning policy comes in.
I think your last suggestion is good
cabal install haxml Downloading HaXml-1.13.3... Note: the recommended version is HaXml-1.13.3 but latest version is HaXml-1.19, use cabal install haxml-1.19 if you want that version.
I would have this message pop up for both cabal install and cabal upgrade -- especiallly since with cabal upgrade the result was for me completely bafflling.
Ok, so that we do not forget this, would you mind filing a ticket to explain the confusion and the suggested solution. Linking to this thread would also help.
http://hackage.haskell.org/trac/hackage/
Duncan
On Mon, 2008-11-24 at 15:16 +0100, Thomas Hartman wrote:
I have run into another issue with cabal packaging, which seems related to the issues discussed above. (see attached tar file for complete example of failure scenario)
If I have a cabal package that depends on two other packages -- package xml-parsec requires HaXml == 1.19.4 (the latest) -- package HAppS-Server requires HaXml == 1.13.3 (the default)
ghc --make testDepConflict.hs works fine.
Yes, it happens to work.
But I can't install via cabal without, I guess, breaking out the conflict into a separate cabal package.
But cabal does not have enough information to know that it is going to work, and in many similar situations it'll fail. So it errs on the side of caution. The potential problem is that types defined in the two different versions of HaXml get used together in your package. Obviously that's not happening in your example but consider the case of different packages using different versions of the bytestring package and you would see type errors where different versions of the bytestring type get equated. Specifically the cabal install solver tries to find a solution that uses at most one version of each package. So that's why it declares that those two packages conflict. There's not a lot more we can do without having more information. For example if we know that the two packages you're using do not re-export any types from the HaXml package, and we could somehow declare and enforce such "private" build dependencies then that would be more information and the solver could allow private versions of a package to be different. Duncan
Thomas Hartman wrote:
When I specify
Build-Depends: base, parsec, HaXml >= 1.19.4
in xml-parsec.cabal
it does install correctly.
I just fixed xml-parsec.cabal and uploaded it on hackage: http://hackage.haskell.org/cgi-bin/hackage-scripts/package/xml-parsec-1.0.3
[...]
//Stephan -- Früher hieß es ja: Ich denke, also bin ich. Heute weiß man: Es geht auch so. - Dieter Nuhr
deduktionstheorem:
Thomas Hartman wrote:
When I specify
Build-Depends: base, parsec, HaXml >= 1.19.4
in xml-parsec.cabal
it does install correctly.
I just fixed xml-parsec.cabal and uploaded it on hackage: http://hackage.haskell.org/cgi-bin/hackage-scripts/package/xml-parsec-1.0.3
Note that packages that depend on the 'experimental' versions of things (in particular Haxml 1.19.* can't be packaged for Arch either, as we can only install one version of the haskell-haxml package). -- Don
Don Stewart wrote:
[...]
Note that packages that depend on the 'experimental' versions of things (in particular Haxml 1.19.* can't be packaged for Arch either, as we can only install one version of the haskell-haxml package).
In this case we definetely need haxml-1.19. IIRC we even committed patches to the haxml repository, when we were developing Barracuda a year ago :) //Stephan -- Früher hieß es ja: Ich denke, also bin ich. Heute weiß man: Es geht auch so. - Dieter Nuhr
participants (4)
-
Don Stewart -
Duncan Coutts -
Stephan Friedrichs -
Thomas Hartman