[Haskell-cafe] cabal install HaXml installs wrong version unless I specify the version number
Thomas Hartman
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.
_______________________________________________
Haskell-Cafe mailing list
Haskel...@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Thomas Hartman
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 <tphy...@gmail.com>:
Duncan Coutts
> 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
Thomas Hartman
(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 <duncan...@worc.ox.ac.uk>:
Duncan Coutts
> 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)
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/
Don Stewart
> Thomas Hartman wrote:
> > When I specify
> >
> > Build-Depends: base, parsec, HaXml >= 1.19.4
> >
> > in xml-parsec.cabal
> >
> > it does install correctly.
>
> 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
Stephan Friedrichs
> [...]
>
> 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
Duncan Coutts
> 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.