On Mon, 2009-02-02 at 23:56 +0100, Jürgen Nicklisch-Franken wrote:

I recently had some (well actually a lot of) troubles with cabal install which are not over. I installed ghc-6.10 on Windows with Cygwin and the fetched cabal-install 0.6.0.

When I then tried to install a package it had regex-posix as dependency it fails to install the newest version package. This was because it doesn't find the c header files. So I tried to use the --extra-include-dirs=PATH flag, but this didn't help, and I guess it was because it was the c2hs preprocessor which didn't get it.

Do you have any more details on that? It's the 'hsc2hs' pre-processor btw. Confusingly there is a similar pre-processor called 'c2hs'.

So I did a manual install of the package and somehow did it.

That's interesting. It should be the same either way. More details would be interesting.

But although ghc-pkg listed the package, when I next time called cabal install it started with installing the package that was already installed. When called with a verbose flag I saw that cabal-install detected that the package was not installed by cabal install. However why does it try to reinstall an already installed package? How does it know, which packages are installed with cabal install?

Actually it does not track which agent installed the package. If you run with --dry-run -v it gives some explanation for what it is doing and why it might think it needs to reinstall the package. If you paste that output we might be able to see what is going on. There is one specific problem with these symptoms that's been fixed in the development version, but there are some other reasons why the solver might choose to reinstall a package.

I then changed the version of the required regex-posix package to the exact version of the lib pre-installed with ghc on Windows. Yet I can never use cabal upgrade again, because it will always fail.

cabal upgrade isn't such a good idea anyway. I'd stick to the install command. The only difference is that upgrade tries to install the latest version all dependencies too, and that tends to lead to problems. I'm considering disabling the feature for now.

Is their any way to exclude a package from the cabal install process?

There is a flag --constraint="foo == 1.0" which is quite handy. The next version may or may not have a way to specify a constraint to always pick an installed version of a particular package. It depends if there is enough time.

I realised as well that there is no way to ever un-install a package installed with cabal-install, as far as I see. This is not satisfactory, right?

Right. Currently only by using ghc-pkg to unregister and the file manager to delete the files. For some reason uninstall never seems to be as high on users priorities as other bugs and features. At least that is my impression. Of course if people help out we'll get round to it sooner.

I regret as well that no option exist to have the source code expanded (I mean from tar.gz), which can be useful if you want to look up some library code later, which I happen to do frequently.

There is in the development version cabal unpack foo

I regret as well that there is no way to adopt a cabal file to my needs when using cabal install, which I find sometimes necessary.

unpack is great for that.

As cabal install is supposed to become a standard way of installing Haskell packages, at least for developers, it would be necessary to have some documentation on it, other then just explaining command line parameters.

I would very much appreciate some help with the documentation. We already have a Cabal user guide and there are not that many extra things in the command line interface of cabal-install.

E.g. if you install some packages as user, which it does by default, it will later not be possible to install other packages global, which anyone using cabal install should know. (Or am I wrong)

Global packages cannot depend on user ones. So installing something globally will also install all of its dependencies globally.

So please help us from spending our time with stupid install problems, and make the road for new Haskell users as smooth as possible, and installation is a big issue for them.

That is what we're trying to do :-). That is what this whole project is about. I can assure you it used to be much harder than it is now. We're making progress but with more people helping we could make progress quicker :-) Duncan