> Please note that Berp is currently in a very early stage of development. Many aspects of Python 3 are not yet implemented, and there are lots of rough edges to the code.
CLPython (http://common-lisp.net/project/clpython/) is
an open-source implementation of Python written in
Common Lisp.
It bridges the Python and Lisp worlds, so you can:
* access Python libraries from Lisp;
* access Lisp libraries from Python.
Runs on 6 different CL implementations. Like Berp it can interpret and compile if the underlying CL implementation supports compilation.
This is pretty usual when it comes to major revision changes in the compiler or standard library with many languages.
This is what you should do:
1. checkout berp from GitHub
2. try to build using cabal in the checked out source tree
3. if there are failing dependencies, hack Cabal build files. this case is probably trivial and berp developers have left containers < 0.4 without a good reason (I may be wrong here, see what's changed in the "containers" package).
There is a workaround for the issues with language-python. One can do:
cabal fetch language-python
cabal unpack language-python
edit the language-python.cabal file updating the containers dependency to 0.4.0.0 then change the version number of language-python itself to 0.3.3
cabal configure
cabal install
However, this will not fix the more obtuse problem:
Warning: This package indirectly depends on multiple versions of the same
package. This is highly likely to cause a compile failure.
package haskell98-1.1.0.1 requires process-1.0.1.5
package ghc-7.0.3 requires process-1.0.1.5
package Cabal-1.10.1.0 requires process-1.0.1.5
package berpinterpreter-0.0.3 requires process-1.0.1.5
I believe the only solution for this problem is to rebuild the entire Haskell platform from source, and if that fails, to format and reload the entire machine.
But you know, keep voting this thread up because Hackhell is awesome.
This sounds sadly like my experiences trying to get the Yi editor to install. I love Haskell in theory, but the build system is so painful if you aren't an expert!
The same can be said about Ruby, except that my experiences with Ruby are worse than with Haskell. With Haskell, you can get a pretty nice "batteries included" setup by installing the latest Haskell platform package.
With Ruby, you have to learn to use rvm, bundler and whatnot just to get a recent version of Ruby installed. Many distributions ship with quite old versions of Ruby and the Ruby official release tarballs have been unreliable (version number doesn't change, tarball contents does, etc).
Lots of languages seem to suffer from similar problems.
When you "cabal unpack language-python" and fix the dependencies, make sure you boost its minor version number (e.g: from: 1.0.3 to 1.0.3.1), otherwise cabal-install will ignore your custom install of the package and will revert to the one from the repositories.
cabal-install is a big hurdle -- must be improved for faster Haskell adoption.
