While trying out the cabal sandbox I found that you cannot install different versions of base and some other packages in sandbox as pointed out in this answer.
I wonder which packages are hardwired into GHC. Is there a complete list somewhere?
I could not find it using google.
I don't just want to get the list of packages that gets installed with ghc. I want to know which packages are so intrinsic to GHC that you cannot install multiple versions of those packages even in a sandbox.
In other words, Which packages are not at all amenable to cabal sandbox?
If you run ghc-pkg list, there should be two lists of packages: those installed in /usr/local/lib/ghc (or wherever GHC is installed), and those in ~/.ghc/. The packages in /usr/local/lib/ghc come with GHC.
Related
I'm in situation where I cannot install new package without reinstalling others (my distribution comes without sandbox).
Is it possible to determine which version of each package I should use so that there will be no conflicts with new one included?
How can I encode this set to create new cabal sandbox?
cabal install --dry-run --avoid-reinstalls should give you some output that indicates the installation plan for a particular package, or fail if it cannot avoid reinstalls due to dependencies.
However, sandboxes are really quite helpful. Independent of how you bootstrap your cabal installation (tarballs, distribution packages, etc.), you should probably add ~/.cabal/bin early in your path and then cabal install cabal-install. This should only fail if the latest version of cabal doesn't work on your version of ghc / base.
I'm trying to install two libraries, Elm and yesod-platform, using a cabal sandbox on Ubuntu. The problem is, I'm using xmonad as my window manager. Thus, a bunch of Haskell libraries have been installed by my package manager. When trying to resolve dependencies, it's using the versions of the libraries installed by apt, and thus is giving a "maximum backjumps exceeded" error.
How can I instruct Cabal to ignore any packages not in the Cabal sandbox, so that it will install fresh versinos of these packages in the sandbox and be able to resolve the dependcies?
Too late probably, but still…
I don't know how to do exactly this, but you can try to force cabal to reinstall those packages in sandbox, it will tell you it is dangerous, but as it is in sandbox I believe it not (I can't see how it would break your system/profile packages). But that is kind of impractical solution. And you will have to specify exact version.
The latest cabal-install that I've been using (0.13.3, from the darcs repo) is nice; it lets you know when you might break your GHC installation with reinstalls. What I want to know is this: suppose a cabal install foo would perform a reinstall that would break my GHC. What would happen if I cabal-dev install foo instead? Would I be able to avoid breaking GHC? Could I actually make use of the foo package in a cabal-dev sandbox, or would it just be a broken sandbox?
Example: yesod, GHC 7.4.1, cabal-dev 0.9 built from github source, Cabal 1.14.0 library.
Just to clarify, if I am understanding you right, you are not breaking GHC in either case. I believe you are referring to installing a package, which then reinstalls one of the underlying dependencies of another package, therefore breaking that other package's dependency chain and preventing it from properly working/compiling when used. Simply removing .ghc from your home folder and re-doing cabal installs typically resolves this problem, albeit in a really painful way.
When you use cabal-dev, all the cabal install steps and ghc-pkg register steps are done in a local sandbox environment. Your global/user ghc packages are not at all touched. Since you typically instantiate one cabal-dev sandbox per project, clashes like described above don't typically happen.
To get to your question - it depends entirely on what is already installed in that particular cabal-dev sandbox. If there are no conflicts, it wouldn't break anything. If you are forcing a --reinstall, you might have to --reinstall any packages in the local cabal-dev sandbox that depend on the package you just reinstalled.
In any case, your GHC installation itself would not break (or be altered in any way) and you can always rm -rf cabal-dev under your project folder and redo cabal-dev install.
Hope this helps.
I'm trying to install hspec, but I'm getting this:
$ cabal install hspec
Resolving dependencies...
cabal: dependencies conflict: ghc-7.2.2 requires containers ==0.4.2.0 however
containers-0.4.2.0 was excluded because ghc-7.2.2 requires containers
==0.4.1.0
What does this even mean?
Also, using ghc 7.2.2, cabal 10.2.
It sounds like you somehow broke your GHC install. GHC 7.2.2 comes with containers-0.4.1.0 (the version of which is the same as for GHC 7.2.1). It might be possible to fix it, but if the global package setup is broken then it would probably be easiest to re-install GHC.
What does ghc-pkg list containers say?
If containers-0.4.2.2 is found only in the per-user install (i.e. the /home/clark/.ghc/${arch}-${os}-7.2.2/package.conf.d output), then rm'ing /home/clark/.ghc/ and re-installing all the packages you installed with cabal install will fix it.
So, this is a bit of a personal problem, but maybe people will have good advice or workarounds.
The problem is about installing cabal-install and haskell-platform under Debian.
When you apt-get install haskell-platform, it ships with cabal-install, and its command cabal is available.
Now this cabal-install is not up-to-date:
> which cabal
/usr/bin/cabal
> /usr/bin/cabal --version
cabal-install version 0.8.0
using version 1.8.0.2 of the Cabal library
But, my understanding of running cabal update is that it updates cabal, but since it is not a "Debian thingy", it puts it in ~/.cabal/bin/.
> ~/.cabal/bin/cabal --version
cabal-install version 0.8.2
using version 1.8.0.2 of the Cabal library
Now my system has 2 cabals, and the one I get by typing cabal is not the one I want to use... Because it'll keep updating the other one instead of itself, and is therefore ineffective.
So what I did was I aliased it in my ~/.bashrc:
alias cabal='~/.cabal/bin/cabal'
Now:
> cabal --version
cabal-install version 0.8.2
using version 1.8.0.2 of the Cabal library
So, my final questions:
Is there a deb repository that holds cabal 0.8.2?
Could my current solution lead to problems? (For instance, which cabal still points to my useless /usr/bin/cabal, so if scripts use this command they'll get fooled...)
Did someone come up with a better solution? (Mine is a bit ad-hoc but that's all I could come up to with my poor knowledge of what is happening behind the scenes...)
Please correct me if anything I say above is wrong or inaccurate.
What I do is installing cabal with the --global flag. This will install cabal into /usr/local/bin/cabal, thus it will always superseed the Debian packages cabal.
Another way, is to generally avoid the Debian packages and install the Haskell platform straight from its source. This approach is also better, if you always want to have the latest releases of the Haskell libs.
I keep my user-local $HOME/.cabal/bin in the front of the PATH.
I install only ghc6, ghc6-prof, ghc6-doc and cabal-install from the distribution packages. I don't use distribution cabal-install for anything more than to bootstrap the new ~/.cabal.
All the rest I install with cabal install, including the newer cabal itself.
When I want to use newer GHC, I deploy it in /usr/local/stow/ghcVERSION, and enable it with GNU stow (it adds symlinks in /usr/local which, again, has precedence in my PATH). When I want to switch back to the distribution GHC I just run stow -D to remove all symbolic links to it.
I consider using cabal-dev to have project-specific cabal installations, and avoid broken dependencies which happen with cabal from time to time.
As a matter of fact I don't use Haskell Platform at all because I don't need all of it and find it easier to be able to install individual libraries. I do not install distribution libraries, because not all of them are available or are exactly the versions I need; and it is much easier to control conflicts if all of them are installed in the same place (~/.cabal in my case). I do not install anything with --global, because I think it is wrong and difficult to rollback.
Of course this information gets out of date, but yes, Debian unstable and testing have, at the time of writing, cabal-install 0.10.2.
Generally, the Debian packaging of Haskell stuff is aimed at users who want a set of packages that is known to work together, i.e. no dependency hell, at the expense of not always having the latest and greatest. This includes cabal-install. I use cabal-install from the repositories, and only to install those libraries that have not been packaged for Debian yet.
Disclaimer: I am one of the guys that create those packages for Debian.
On Ubuntu I also tend to install GHC via stow, ignoring the system packages altogether.
One slight twist from jetxee's approach is that I do install the Haskell Platform (from source), lumping it in with the GHC stow directory. I suppose I ought to call the paths /usr/local/stow/haskell-platform-VERSION, but I tend to use /usr/local/stow/ghc-VERSION instead.