I want to run a program that demands a specific version of the base package. This version is not the one that comes with my OS's version of Haskell hence I apparently can't use my OS's version of Haskell.
It would be great of conda worked with Haskell the way it works with Python so as to create an environment for a specific version of Haskell, but such is not the case. Nor is it the case that Haskell's sandbox feature permits one to specify a version of base let alone Haskell itself.
PS: Frustratingly, the SE question "How to install an older version of base in Haskell" ended up answering another question without changing the title to reflect the question it did answer.
There is a tool that works even better then conda in Haskell called stack. Version of base is hardwired with version of ghc that is installed. You can get stack installed first and it will install version of the ghc you need automatically:
$ curl -sSL https://get.haskellstack.org/ | sh
This command will automatically install ghc-8.6.5, which is specified by lts-14.22 resolver and will make all packages available for you on demand including base
$ stack --resolver lts-14.22 ghci
To obtain the resolver specification:
Go to this table of all packages that come installed with a
particular GHC version.
If a desired base version is not available, find the scroll bar at
the bottom of the table and scroll to the right until you find one.
Say it is base-4.11.1.0, then look at the header of the column for
the ghc version that ships with this base.
In this example either one of this versions of ghc: 8.4.4, 8.4.3,
8.4.2 will have that version of base.
Go on the stackage.org home page and find in
the matching lastest resolver in the list "Latest LTS per GHC
version".
In this example, any lts-12 will do for the base above.
Latest nightly resolver will always have the newest ghc and base available on stackage.
Related
I'm a Haskell newcomer and have Haskell installed on my (Mac) machine; I'm trying to use newsynth (https://www.mathstat.dal.ca/~selinger/newsynth/, http://hackage.haskell.org/package/newsynth). In my terminal in the same place where I installed Haskell (home directory) I ran the command cabal install newsynth as suggested by the package authors. However, I can't figure out how to actually access anything from the package from the command line, let alone within a particular file.
In GHCi Prelude, I tried running commands of the form import Quantum and import Quantum.Synthesis.Diophantine but always get an error message. (e.g. in contrast, import Data.Complex works just fine.)
(I'm sure I'm missing something pretty obvious, but I only began with Haskell on Monday, and need to spin up some newsynth code by next week, which is why I'm not starting from the ground up.) Any advice on (1) how to run newsynth's functions from GHCi and (2) how to incorporate them into .hs files would be greatly appreciated. Thanks!
Edit: cabal --version returns
cabal-install version 3.2.0.0 (newline) compiled using version 3.2.0.0 of the Cabal library
Quoting a comment:
[cabal --version] returns: cabal-install version 3.2.0.0 (newline) compiled using version 3.2.0.0 of the Cabal library
It seems the installation instructions in the project page you linked to haven't been updated for cabal-install 3+ yet (in fairness, cabal-install 3 is relatively recent). In any case:
If all you want is running ghci and trying those modules out, with no strings attached, use cabal install --lib newsynth. That will make the newsynth package available in GHC's global environment (see the cabal install entry in the Cabal User Guide for further information).
Since you ultimately want to use the package in the code you'll have to write, though, my recommendation is using cabal init to create a new project for your code. Then, edit the .cabal file of the project to add newsynth to its build-depends section, and that's it: the package will be installed (if it isn't already) and made available in the context of your project the next time you do a cabal build to build the project, or a cabal repl to run GHCi in the context of your project. In that case, there is no need to use the cabal install command at all.
I am trying to learn Haskell from the book Learn You a Haskell by Miran Lipovača. Both the book and haskell.org recommends installing the Haskell Platform but there is no download for Manjaro Linux (Arch based) which I use.
I found this guide from 2014 and decided to install the packages from Manjaro's repository. This worked fine until I wanted to use haskell-mode in Emacs. I troubleshooted this and found out that it was a problem with the packages (Stack mainly).
Looking for ways to fix this I found this Reddit thread, which describes ways to install Haskell (not the Platform), and problems with the packages. I followed one of the comments and ended up installing Stack (and GHC) with the script as described here:
wget -qO- https://get.haskellstack.org/ | sh
stack setup
stack update
My questions are related to this:
Is this the recommended starter way to install a functioning Haskell (Platform) on Linux (Manjaro) in 2018? If not: what is the/a way to do it?
Haskell Platform contains: GHC, Cabal, Stack, and some packages. GHC and Stack are installed, how do I install Cabal through Stack?
Do I need Cabal (Stack seems to have overlapping functionality)?
Looking at the packages of the Haskell Platform, what, if anything, am I missing by installing Stack as described above? Looking in $HOME/.stack/programs/x86_64-linux/ghc-tinfo6-nopie-8.2.2/lib/ghc-8.2.2 many of these seems installed already.
Here's a (long) alternative answer. Note that I used to recommend Stack for beginners, too, but I've since changed my mind.
TL;DR: Either Haskell Platform or a pure Stack installation can provide you with everything you need, and you won't be "missing" anything by choosing one or the other. You'll probably find it easiest to skip Stack and install Haskell Platform using the "Generic" Linux installer, because it comes with everything you need and the setup will more closely matched what's described in the LYAH book. You can install Stack later when you're doing more serious development on multiple projects. If you prefer to stick with a pure Stack installation, I'd suggest starting with a "global project only" workflow. Either way, you can use "haskell-mode" with some configuration fixes suggested below (including a key setting that will be required if you're working in the global project of a Stack-only installation).
Here's the long answer...
Stack vs. Platform vs. Cabal
The LYAH book pre-dates Stack, which is certainly the main reason it doesn't mention it. At haskell.org, they recommend using either a minimal installer, Stack, or the Haskell Platform. All three methods are perfectly reasonable ways in 2018 to set up a working Haskell environment. They differ both in the ways they choose to isolate different versions of the compiler and/or libraries into "sandboxes" for development work, and in how much they install initially, but there's nothing "missing" from any one of them that can't be installed on demand. Depending on which you choose, there will be some differences in your workflow (see below).
Both Stack and Cabal are combined package managers and build tools. (Stack has the added ability to actually bootstrap an entire Haskell installation, which is why it's also an installation method in its own right.) While you're working through LYAH, you won't actually be using the "build tool" functionality directly on your own projects. (The built-in build facilities of GHC are more than adequate for building small, multi-module projects.) You'll just need the package manager functionality to install additional libraries.
Since Stack and Cabal manage their packages separately, if you're using Stack, you'll have no particular need to use Cabal directly. You can install it if you want (and in fact, Stack makes use of Cabal for some esoteric functionality, like "stack solver", and will require it to be installed in those cases):
$ stack install cabal-install
But, even though this will put "cabal" into "$HOME/.local/bin" (and you'll want to make sure this is in your path), you'll find that you need to jump through hoops to run it:
$ stack exec --no-ghc-package-path cabal -- list
and it doesn't really do anything useful as far as your Stack environment is concerned.
Update: A note on the "$HOME/.local/bin" path. It looks like the installation script from https://get.haskellstack.org/ may install Stack itself to /usr/local/bin/stack by default if there's no existing installation. However, it should display a warning to put $HOME/.local/bin in your path. If you upgrade Stack in the future with stack upgrade, it'll install the new version of stack there, and that directory will also be used if you install packages that include binaries. For example, stack install hlint will install the Haskell Lint program hlint to that directory. So, it's a good idea to have it in your path and somewhere before /usr/local/bin.
What's Missing with Stack
I think that covers your first three questions. For your last, the main thing you're missing having installed Stack instead of the Haskell Platform is that, by design, Stack doesn't really install anything globally other than "stack" itself. So, all your Haskell work including running the Haskell interpreter ("ghci") or compiler ("ghc"), all needs to be done within a Stack environment, either using a specific corresponding Stack command:
$ echo 'main = putStrLn "Hello, world!"' > Hello.hs
$ stack ghc -- Hello.hs
[1 of 1] Compiling Main ( Hello.hs, Hello.o )
Linking Hello ...
$ ./Hello
Hello, world!
$
or else using "stack exec" to run a generic program within an appropriate Stack environment. For example, it can sometimes be helpful to run a Bash shell under stack, after which things behave sort of like a globally installed Haskell Platform environment:
$ stack exec bash
$ ghci
GHCi, version 8.2.2: http://www.haskell.org/ghc/ :? for help
Prelude> :quit
$ ghc -O2 Hello.hs
[1 of 1] Compiling Main ( Hello.hs, Hello.o ) [flags changed]
Linking Hello ...
$ exit
$ ghc
The program 'ghc' is currently not installed. ...
$
The other thing you're missing is that the Haskell Platform installs a whole bunch of common libraries by default, while a fresh Stack environment starts with almost nothing (not even the compiler, before you run stack setup). While working through LYAH, you may find you need to periodically install additional libraries. For example, in the Input and Output chapter, the examples using random numbers (module System.Random) will require you to run:
$ stack install random
and restart your interpreter.
Recommendation to Use Haskell Platform
Because Stack is a little complicated and you won't really need the facilities it provides at the beginning, you may find the Haskell Platform easier to use when you're starting out. (The "Generic" installer should work fine on your distribution.) It comes with everything installed, and the way you use it will more closely match the way things are described in LYAH. Together with haskell-mode, you should have a pretty decent Haskell environment.
In general, there should be no issue having Stack and the Haskell Platform installed side-by-side (as evidenced by the fact that Haskell Platform actually includes Stack). Stack will maintain everything separately under the "$HOME/.stack" subdirectory, so there will be no interference between compilers or packages or anything. Note that in this setup, you'll use cabal to manage the packages installed on the Platform side of things, and stack -- obviously -- to manage packages on the Stack side.
Beginner Workflow for a Pure Stack Installation
If you want to stick with your pure Stack installation, I might suggest the following workflow when you're starting out:
You will see references to Stack projects, created with "stack new" or "stack init". Avoid these at the beginning, and stick with the stack "global project". This is the implicit project that will be in effect when you run "stack" in a directory that doesn't have a "stack.yaml" file (directly or in a parent directory):
$ cd
$ stack path --project-root
/u/buhr/.stack/global-project
$
When you're working in the global project (i.e., not somewhere under a stack.yaml file), you can invoke the interpreter and compiler with:
$ stack exec ghci
$ stack ghc -- -O2 Hello.hs
and they will both have access to any additional libraries (packages) you've installed using commands like:
$ stack install random
Updated: A note on the difference between stack ghci and stack exec ghci. The former is intended to run GHCi within the context of a local project (i.e., working under a stack.yaml file). It passes some additional flags to hide globally installed packages and to automatically make available modules from your package. When working in the global project, I don't think there's any practical difference except that stack ghci generates a warning; and no matter which you use, you'll need to load your own modules explicitly with :load Whatever.hs. There's a little more info on the difference on this Stack documentation page, particularly at the bottom where it tries to explain the difference.
Eventually, you may switch to a workflow that uses Stack projects. This will involve using stack new to create a new Stack project directory, stack setup to install/link a private compiler version into that directory, and then modifying the project's xxx.cabal file (and possibly its stack.yaml file) to indicate which additional packages are required, instead of using stack install. It's all a little complicated when you just want to get started writing code.
You may also see reference to Intero, an Emacs mode designed specifically for Stack. Intero is very nice, but it doesn't work very well when working on files in the global project. It'll tend to want to start up the interpreter in the directory "~/.stack/global-project", which is pretty useless. (I use Intero, but I've patched it to behave better in this respect.)
Configuring Haskell-Mode (for Either Platform or Stack)
It's probably best to stick with "haskell-mode" instead, and think about Intero when you start using non-global projects. I'd suggest installing "haskell-mode" from MELPA as per the instructions, but adding the following to your .emacs file instead of what's suggested in the documentation:
(require 'haskell)
;; add capability to submit code to interpreter and mark errors
(add-hook 'haskell-mode-hook 'interactive-haskell-mode)
;; add missing keybindings for navigating errors
(define-key interactive-haskell-mode-map (kbd "M-n") 'haskell-goto-next-error)
(define-key interactive-haskell-mode-map (kbd "M-p") 'haskell-goto-prev-error)
(define-key interactive-haskell-mode-map (kbd "C-c M-p")
'haskell-goto-first-error)
;; merge this with your existing custom-set-variables
(custom-set-variables
;; NOTE: include following line to work around haskell-mode
;; bug if using GHC >= 8.2.1.
;; See: https://github.com/haskell/haskell-mode/issues/1553
'(haskell-process-args-stack-ghci
'("--ghci-options=-ferror-spans -fshow-loaded-modules"
"--no-build" "--no-load"))
;; some options suggested in the haskell-mode documentation
'(haskell-process-auto-import-loaded-modules t)
'(haskell-process-log t)
'(haskell-process-suggest-remove-import-lines t)
;; make sure "stack ghci" is used, even in the global project
'(haskell-process-type 'stack-ghci))
I've tested this with a pure Stack installation using "haskell-mode-20171022.26", and it seems to work fine. I can load a new Haskell file in the global project, submit it to an interactive session with "C-c C-l", and browse highlighted errors in the source file with "M-n" and "M-p". (The errors appear in the mini-buffer.)
If you decide to use the Haskell Platform instead, I think all of this "haskell-mode" configuration will still apply, except you should remove the very last customization line. (The default haskell-process-type of auto will pick something appropriate.)
Hope that helps!
You have three choices.
Haskell Platform
It is a possibility but not a popular choice for many reasons which you will discover in due time if you choose to go this way. You will have a much better experience and get much better support with either Stack or Nix. Which of those two people use seems to be mostly about personal preference. They are different beasts but to a beginner the differences will not be immediately obvious so there's little hope that you will be able to make an "informed decision". Just pick one and reevaluate later.
Stack
This is what I would suggest to anyone (not familiar with Nix) wanting to get started with Haskell quickly. Period. You do not need to separately install anything, Stack will handle all the Haskell stuff for you. You don't normally ever use cabal directly with Stack. stack build uses cabal internally but you don't need to worry about that. One thing to note, Stack is not a package manager. It's a build tool. It doesn't normally install anything. It does however fetch all the dependencies that it needs and stores them in ~/.stack together with other things.
Nix
This is what I use personally so I may be biased but I think this is the best solution overall in the long term. The caveat is that there is a rather steep learning curve and you are given many chances to shoot yourself in the foot when starting out.
I highly recommend starting with Stack but keeping an open mind about Nix as your journey with Haskell continues.
I have a project that I want to compile with LTS 2, but I'm stuck trying to work around this well-known bug in OS X 10.11.
Can I somehow specify a newer version of Cabal to use with ghc-7.8.4? Note that the project only really compiles with GHC 7.8.*.
Edit:
Really meant Cabal, not cabal-install.
Edit 2:
Actually, the answer to this question doesn't really solve my concrete problem (compiling helium, which requires GHC <= 7.8.4), because the bug is not specific to Cabal, but rather to unix, which GHC < 7.10 depends upon.
I think the problem is related not just to Cabal library version (btw, stack doesn't use or need cabal-install), but also to GHC version. Stack's FAQ mentions an item about this error, but I think it didn't help for me and I just upgraded to 7.10.2 at the time.
Here's a recipe for installing ghc-7.8.4 into the directory of your choice:
Download the "bindist" from https://www.haskell.org/ghc/download_ghc_7_8_4#macosx_x86_64
Untar it into a scratch directory
Create the destination directory, e.g. $HOME/my-prefix.
In the scratch directory run:
$ ./configure --prefix=$HOME/my-prefix
$ make install
Now ghc may be found in $HOME/my-prefix/bin.
As noted in Michael Snoyman's comment, there is stack setup --upgrade-cabal to do just that. That's it for the answer to this question.
In my specific case (XY problem), for that to work I had to do the usual work-around for that El Capitano related bug, which is explained here. So I enabled rootless, ran the upgrade command and re-enabled rootless.
To no avail I'm afraid: The bug is specific to unix < 2.7.1.0, which GHC 7.8.4 also depends on. So even after upgrading cabal, I can't compile anything in lts-2 unless I disable rootless, which is pretty annoying.
Actually it's kinda depressing that the GHC folks decided not to file a new minor release with the updated unix package. This means that no realistic/recent OS X configuration can build anything which involves GHC < 7.10.
I'm experimenting a problem with the interaction between the ghc-mod plugin in emacs, and NixOS 14.04. Basically, once packages are installed via nix-env -i, they are visible from ghc and ghci, recognised by haskell-mode, but not found by ghc-mod.
To avoid information duplication, you can find all details, and the exact replication of the problem in a VM, in the bug ticket https://github.com/kazu-yamamoto/ghc-mod/issues/269
The current, default, package management set up for Haskell on NixOS does work will with packages that use the ghc-api, or similar (ghc-mod, hint, plugins, hell, ...) run time resources. It takes a little more work to create a Nix expression that integrates them well into the rest of the environment. It is called making a wrapper expression for the package, for an example look at how GHC is installed an operates on NixOS.
It is reasonable that this is difficult since you are trying to make a install procedure that is atomic, but interacts with an unknown number of other system packages with their own atomic installs and updates. It is doable, but there is a quicker work around.
Look at this example on the install page on the wiki. Instead of trying to create a ghc-mod package that works atomically you weld it on to ghc so ghc+ghc-mod is an atomic update.
I installed ghc+ghc-mod with the below install script added to my ~/.nixpkgs/nixpkgs.nix file.
hsEnv = haskellPackages.ghcWithPackages (self : [
self.ghc
self.ghcMod
# add more packages here
]);
Install package with something like:
nix-env -i hsEnv
or better most of the time:
nix-env -iA nixpkgs.haskellPackages.hsEnv
I have an alias for the above so I do not have to type it out every time. It is just:
nixh hsEnv
The down side of this method is that other Haskell packages installed with nix-env -i[A] will not work with the above installation. If I wanted to get everything working with the lens package then I would have to alter the install script to include lens like:
hsEnv = haskellPackages.ghcWithPackages (self : [
self.ghc
self.ghcMod
self.lens
# add more packages here
]);
and re-install. Nix does not seem to use a different installation for lens or ghc-mod in hsEnv and with the ghc from nix-env -i ghc so apparently only a little more needs to happen behind the scenes most of the time to combine existing packages in the above fashion.
ghc-mod installed fine with the above script but I have not tested out its integration with Emacs as of yet.
Additional notes added to the github thread
DanielG:
I'm having a bit of trouble working with this environment, I can't even get cabal install to behave properly :/ I'm just getting lots of errors like:
With Nix and NixOS you pretty much never use Cabal to install at the global level
Make sure to use sandboxes, if you are going to use cabal-install. You probably do not need it but its there and it works.
Use ghcWithPackages when installing packages like ghc-mod, hint, or anything needs heavy runtime awareness of existing package (They are hard to make atomic and ghcWithPackages gets around this for GHC).
If you are developing install the standard suite of posix tools with nix-env -i stdenv. NixOS does not force you to have your command line and PATH cultured with tools you do not necessarily need.
cabal assumes the existence a few standard tools such as ar, patch(I think), and a few others as well if memory services me right.
If you use the standard install method and/or ghcWithPackages when needed then NixOS will dedup, on a package level (If you plot a dependency tree they will point to the same package in /nix/store, nix-store --optimise can always dedup the store at a file level.), many packages automatically unlike cabal sandboxes.
Response to comment
[carlo#nixos:~]$ nix-env -iA nixos.pkgs.hsEnv
installing `haskell-env-ghc-7.6.3'
these derivations will be built:
/nix/store/39dn9h2gnp1pyv2zwwcq3bvck2ydyg28-haskell-env-ghc-7.6.3.drv
building path(s) `/nix/store/minf4s4libap8i02yhci83b54fvi1l2r-haskell-env-ghc-7.6.3'
building /nix/store/minf4s4libap8i02yhci83b54fvi1l2r-haskell-env-ghc-7.6.3
collision between `/nix/store/1jp3vsjcl8ydiy92lzyjclwr943vh5lx-ghc-7.6.3/bin/haddock' and `/nix/store/2dfv2pd0i5kcbbc3hb0ywdbik925c8p9-haskell-haddock-ghc7.6.3-2.13.2/bin/haddock' at /nix/store/9z6d76pz8rr7gci2n3igh5dqi7ac5xqj-builder.pl line 72.
builder for `/nix/store/39dn9h2gnp1pyv2zwwcq3bvck2ydyg28-haskell-env-ghc-7.6.3.drv' failed with exit code 2
error: build of `/nix/store/39dn9h2gnp1pyv2zwwcq3bvck2ydyg28-haskell-env-ghc-7.6.3.drv' failed
It is the line that starts with collision that tells you what is going wrong:
collision between `/nix/store/1jp3vsjcl8ydiy92lzyjclwr943vh5lx-ghc-7.6.3/bin/haddock' and `/nix/store/2dfv2pd0i5kcbbc3hb0ywdbik925c8p9-haskell-haddock-ghc7.6.3-2.13.2/bin/haddock' at /nix/store/9z6d76pz8rr7gci2n3igh5dqi7ac5xqj-builder.pl line 72.
It is a conflict between two different haddocks. Switch to a new profile and try again. Since this is a welding together ghc+packages it should not be installed in a profile with other Haskell packages. That does not stop you from running binaries and interrupters from both packages at once, they just need to be in their own name space so when you call haddock, cabal, ghc, there is only one choice per profile.
If you are not familiar with profiles yet you can use:
nix-env -S /nix/var/nix/profiles/per-user/<user>/<New profile name>
The default profile is either default or channels do not which one it will be for your set up. But check for it so you can switch back to it later. There are some tricks so that you do not have to use the /nix/var/nix/profiles/ directory to store you profiles to cut down on typing but that is the default location.
I'm currently trying out web development frameworks for haskell and I recently came across yesod. It seemed pretty interesting so I installed it using cabal, however I'm not able to run the development server. Following their getting started instructions here's the result:
$ yesod init
$ cd mysite
$ yesod devel
Configuring mysite-0.0.0...
Testing files...
Rebuilding app
yesod: bind: resource busy (Address already in use)
Preprocessing library mysite-0.0.0...
Preprocessing executables for mysite-0.0.0...
Building mysite-0.0.0...
Controller.hs:16:7:
Could not find module `Data.Dynamic':
It is a member of the hidden package `base'.
Perhaps you need to add `base' to the build-depends in your .cabal file.
It is a member of the hidden package `base-3.0.3.2'.
Perhaps you need to add `base' to the build-depends in your .cabal file.
Use -v to see a list of the files searched for.
Testing files...
Testing files...
^^ above line just keeps repeating...
I'm assuming it has something to do with the Data.Dynamic module but I don't know how to go about fixing it.
Additional Info
Running Ubuntu 10.10 Maverick
ghc version:
$ ghc --version
The Glorious Glasgow Haskell Compilation System, version 6.12.1
I haven't run into this specific issue, but the error message looks like it's a simple question of GHC being unable to find version 3.0.3.2 the package "base." This version has been buildable since GHC 6.9, so you should have it. Try running the following command:
ghc-pkg check
This will tell you if there is something wrong with your packages. Cabal can be a bit of a nightmare for dependencies -- partly, it seems, because a lot of Haskell developers underestimate the extent to which their underlying libraries will shift in the future. So they will define a dependency as ">= [version of package x]" without limiting the max version to the one presently available. Or they just leave out version-limiting altogether.
Yesod, I'm happy to say, doesn't fall into this trap. But several of the libraries it depends on do. When you start developing in Haskell, learn this lesson: never assume that future versions of a library won't break your code. They will. A lot.
If ghc-pkg comes up with broken packages, you may need to clean up/uninstall/reinstall these packages until they are either cleaned up or hidden. (Just do ghc-pkg hide [package name] to tell ghc to ignore that package.
Your next problem is that hidden base package. Try the following:
ghc-pkg list | grep base
If you see brackets around the library, that means it's hidden. The package base-3.0.3.2 might show up as hidden (although that's a bit unlikely, as that's where the backward-compatible Prelude lives). If it is hidden, try to unhide it with the following command:
ghc-pkg expose base-3.0.3.2
Now try re-running yesod devel and see how it goes. Best case scenario is that it works. If not, let us know.
According to the Yesod in Five Minutes guide, you appear to be missing the a call to the command "cabal install" between your "cd mysite" and "yesod devel". It may need to install further packages based on what your responses were during "yesod init", such as which database you want to use.
Also, you may want to check that the port is not currently being used, as you have the "Address already in use" shown in your transcript.
First, it would be a good idea to resolve any broken packages reported by ghc-pkg check, by removing/reinstalling/upgrading them.
Next, can you manually cabal build the mysite app without trouble ? If your mysite.cabal actually does not specify base in the build-depends list, you should follow the suggestion to add that.
The repeating Testing Files message is normal for current yesod devel, it is polling your source files.