I have stack installed on my computer for haskell:
Developers-MacBook-Pro:~ developer$ stack ghci
Configuring GHCi with the following packages:
GHCi, version 8.0.1: http://www.haskell.org/ghc/ :? for help
Loaded GHCi configuration from /private/var/folders/2x/t_2cl03x2092dkzvc702d7lc0000gn/T/ghci2170/ghci-script
Prelude>
As you can see version is still 8.0.1. Then I upgraded the stack as follow:
Developers-MacBook-Pro:~ developer$ stack upgrade
Current Stack version: 1.3.2, available download version: 1.4.0
Newer version detected, downloading
Querying for archive location for platform: osx-x86_64-static
Querying for archive location for platform: osx-x86_64
Downloading from: https://github.com/commercialhaskell/stack/releases/download/v1.4.0/stack-1.4.0-osx-x86_64.tar.gz
Download complete, testing executable
Version 1.4.0, Git revision e714f1dd3fade19496d91bd6a017e435a96a6bcd (4640 commits) x86_64 hpack-0.17.0
New stack executable available at /Users/developer/.local/bin/stack
After I start stack ghci again and I've got still version 8.0.1, what am I doing wrong?
The image shows, that ghci version 8.0.2 has successfully installed:
The path is /Users/developer/.stack/programs/x86_64-osx/
Update
In the path /Users/developer/.stack/, there is a folder called global-project and I change the yaml as follow:
Now stack ghci run on version 8.0.2:
Developers-MBP:~ developer$ stack ghci
Configuring GHCi with the following packages:
GHCi, version 8.0.2: http://www.haskell.org/ghc/ :? for help
Loaded GHCi configuration from /private/var/folders/2x/t_2cl03x2092dkzvc702d7lc0000gn/T/ghci526/ghci-script
According to https://docs.haskellstack.org/en/stable/faq/#what-version-of-ghc-is-used-when-i-run-something-like-stack-ghci,
The version of GHC, as well as which packages can be installed, are specified by the resolver.
So, to change the version of GHC used when executing stack ghci outside stack projects, do:
Find an existing resolver in ~/.stack/build-plan, e.g. lts-10.4, or download a new resolver you need;
Execute stack config set resolver lts-10.4. Yes it updates ~/.stack/global-project/stack.yaml.
As thus, stack ghci outside stack projects will use GHC 8.2.2, which is the GHC version specified by resolver lts-10.4 (This relationship can be found at https://www.stackage.org/lts-10.4, or in file ~/.stack/build-plan/lts-10.4.yaml which says ghc-version: '8.2.2').
stack is a build tool that coordinates building projects with different versions of GHC and sets of dependencies. So you can upgrade stack independently of ghc.
I'm not quite sure what the expected behavior of stack ghci is when it's run outside of a project directory. Presumably you con configure the default version of ghc to use in that case in your ~/.stack/config.yaml. See: http://docs.haskellstack.org/en/stable/yaml_configuration/
You should also be able to do:
$ stack ghci --with-ghc ghc-7.10.3
But usually the version of ghc is determined by the stackage snapshot you've configured for your project, for instance if you have a stack.yaml with:
resolver: lts-3.3
...you will be using ghc-7.10.3
Related
I install GHC on Windows10 using the recommended Haskell Stack. I want to us GHC without all the Stack overhead for Advent of Code. This was working fine until I tried to get the extra package.
I can install it with Stack, but I don't seem to have a way to get it in the global package database. Haskell Stack apparently does not install the cabal executable and seems to have it locked out of their package database.
How do I install the extra package for use with vanilla GHC?
John Miller#DESKTOP-NENAGQH MSYS /d/dev/AdventOfCode2020
$ stack ghc -- AoC/Utils.hs
[1 of 1] Compiling AoC.Utils ( AoC\Utils.hs, AoC\Utils.o )
John Miller#DESKTOP-NENAGQH MSYS /d/dev/AdventOfCode2020
$ ghc AoC/Utils.hs
[1 of 1] Compiling AoC.Utils ( AoC\Utils.hs, AoC\Utils.o ) [Data.List.Extra changed]
AoC\Utils.hs:3:1: error:
Could not find module `Data.List.Extra'
Use -v (or `:set -v` in ghci) to see a list of the files searched for.
|
3 | import Data.List.Extra
| ^^^^^^^^^^^^^^^^^^^^^^
I don't know whether stack supports installing to the global package DB. cabal does though:
$ cabal install --lib extra
Resolving dependencies...
Up to date
$ ghci
GHCi, version 8.10.2: https://www.haskell.org/ghc/ :? for help
Loaded package environment from /home/simon/.ghc/x86_64-linux-8.10.2/environments/default
Prelude> import Data.List.Extra
Prelude Data.List.Extra>
Ok, so stack can install the cabal executable if you beat at it long enough. The package is called cabal-install and it is not in any resolver, but is on Hackage.
stack install cabal-install
Because it is not in the resolver there is a pretty good chance that the version of Cabal, the library for manipulating cabal packages in Haskell, is not compatible. First, ask stack where it keeps its global config
stack path --config-location
Edit that file to allow for the needed dependencies under extra-deps: Stack will helpfully tell you what they are. It may also be helpful to change the resolver to a newer version in that file while your at it.
Now try
stack install cabal-install
again and if these instructions have not fallen out of date since December 2020 you will get the cabal executable somewhere potentially useful.
Before using cabal you will have to run a cabal update to get the package list.
At this point cabal should manipulate your global package database and stack can install GCH and all its libraries over and over and over again if you want to use it for a project instead. They should just keep out of each other's way.
I'm using stack ghci to start my REPL, based on the answer I got for my question on how to import a module installed with stack. This works fine, but I get initially a warning message Note: No local targets specified, so a plain ghci will be started with no package hiding or package options., followed by a bunch of suggestions about package hiding and options. My guess is that this is because I have not used stack init to setup a project, since I am still in the "playing around and learning" state and don't want a project yet. I have not found an explanation about the meaning of 'no local targets', but the effect to start a plain ghci is exactly what I want at that point. Is there a way to suppress this message? I looked at stack --help, but could not find something suitable.
As the Note (not warning) suggests, a plain ghci is started, which is rather uncommon situation when working with stack.
~$ stack ghci
Note: No local targets specified, so a plain ghci will be started with no package hiding or package options.
You are using snapshot: lts-14.12
If you want to use package hiding and options, then you can try one of the following:
* If you want to start a different project configuration than /home/username/.stack/global-project/stack.yaml, then you can use stack init to create a new stack.yaml for the packages in the
current directory.
* If you want to use the project configuration at /home/username/.stack/global-project/stack.yaml, then you can add to its 'packages' field.
Configuring GHCi with the following packages:
GHCi, version 8.6.5: http://www.haskell.org/ghc/ :? for help
Loaded GHCi configuration from /tmp/haskell-stack-ghci/2a3bbd58/ghci-script
Prelude>
This means though that all you need to do to get the same behavior without the Note is just start ghci manually in the context of global stack environment:
~$ stack exec -- ghci
GHCi, version 8.6.5: http://www.haskell.org/ghc/ :? for help
Prelude>
In case that you want to make sure some package is installed for "playing around and learning" in the ghci session you can supply them as --package arguments
~$ stack exec --package massiv -- ghci
atomic-primops> using precompiled package
cabal-doctest > using precompiled package
scheduler > using precompiled package
massiv > using precompiled package
Completed 4 action(s).
GHCi, version 8.6.5: http://www.haskell.org/ghc/ :? for help
Prelude> import Data.Massiv.Array
Prelude Data.Massiv.Array>
stack exec --ghci as in lehins's answer did not work for me, but stack exec ghci did.
I'm trying to setup a new project using the nightly-2017-08-17 snapshot
stack new test --resolver nightly-2017-08-17
However this gives the following error:
Downloading template "new-template" to create project "test" in test/ ...
Looking for .cabal or package.yaml files to use to init the project.
Using cabal packages:
- test/test.cabal
Selected resolver: nightly-2017-08-17
Unable to parse cabal file: FromString "This package requires at least Cabal version 2.0" Nothing
Cabal is in its latest version:
stack setup --upgrade-cabal
Currently installed Cabal is 2.0.0.2, newest is 2.0.0.2. I'm not upgrading Cabal.
stack will use a sandboxed GHC it installed
For more information on paths, see 'stack path' and 'stack exec env'
To use this GHC and packages outside of a project, consider using:
stack ghc, stack ghci, stack runghc, or stack exec
Is this not the correct way of selecting this nightly snapshot with stack or is this a bug in the tool?
Cabal's file format has changed in the 2.0 release of it (likely because of backpack). You have to use Stack version >= 1.5.1 which bypasses this error. A proper fix for this will be likely released in the next version of Stack. IIRC, the fix is already in the master brach of the stack - so the upgrade via --source-only willl also work for you.
You can read the changelog here to know more information about it.
I am running stack version 1.1.2 x86_64 hpack-0.14.1
$ stack exec which ghc
Run from outside a project, using implicit global project config
Using resolver: lts-5.10 from implicit global project's config file: /home/wisut/.stack/global-project/stack.yaml
/home/wisut/.stack/programs/x86_64-linux/ghc-7.10.3/bin/ghc
but when using stack ghci with GHC.Paths it is return the wrong path
$ stack ghci
Run from outside a project, using implicit global project config
Using resolver: lts-5.10 from implicit global project's config file: /home/wisut/.stack/global-project/stack.yaml
Error parsing targets: The specified targets matched no packages. Perhaps you need to run 'stack init'?
Warning: build failed, but optimistically launching GHCi anyway
Configuring GHCi with the following packages:
GHCi, version 7.10.3: http://www.haskell.org/ghc/ :? for help
Ok, modules loaded: none.
Prelude> GHC.Paths.ghc
"/usr/bin/ghc-7.10.3"
I am running Arch linux with ghc 8.0.1 therefor there is no ghc-7 avaliable outside stack
[wisut#earth ~]$ which ghc
/usr/bin/ghc
[wisut#earth ~]$ ghc --version
The Glorious Glasgow Haskell Compilation System, version 8.0.1
[wisut#earth ~]$ ls -al /usr/bin/ghc
lrwxrwxrwx 1 root root 9 May 24 18:28 /usr/bin/ghc -> ghc-8.0.1
Looking at GHC.Paths source, I have no idea where the value are from. Is it the ENV vars?
{-# LANGUAGE CPP #-}
module GHC.Paths (
ghc, ghc_pkg, libdir, docdir
) where
libdir, docdir, ghc, ghc_pkg :: FilePath
libdir = GHC_PATHS_LIBDIR
docdir = GHC_PATHS_DOCDIR
ghc = GHC_PATHS_GHC
ghc_pkg = GHC_PATHS_GHC_PKG
Running stack exec env didn't see anything.
$ stack exec env | grep -i ghc
Run from outside a project, using implicit global project config
GHC_PACKAGE_PATH=/home/wisut/.stack/global-project/.stack-work/installx86_64-linux/lts-5.10/7.10.3/pkgdb:/home/wisut/.stack/snapshots/x86_64-linux/lts-5.10/7.10.3/pkgdb:/home/wisut/.stack/programs/x86_64-linux/ghc-7.10.3/lib/ghc-7.10.3/package.conf.d
PATH=/home/wisut/.stack/global-project/.stack-work/install/x86_64-linux/lts-5.10/7.10.3/bin:/home/wisut/.stack/snapshots/x86_64-linux/lts-5.10/7.10.3/bin:/home/wisut/.stack/programs/x86_64-linux/ghc-7.10.3/bin:/home/wisut/.local/bin:/usr/local/sbin:/usr/local/bin:/usr/bin:/usr/lib/jvm/default/bin:/usr/bin/site_perl:/usr/bin/vendor_perl:/usr/bin/core_perl
How can I fix the wrong value? How to to config stack to make GHC.Paths return the correct one?
UPD
I tried running stack with --no-system-ghc and it didn't make any difference.
I tried to remove my ~/.cabal and ~/.stack folders. I had to do stack setup, and after stack re-installed the compiler it doesn't give me that wrong path, but it doesn't give me any path, the output of that command is now empty.
I have nothing special in any of Setup.hs too.
You are almost right, the GHC_ variables are CPP definitions coming from custom Setup.hs:
let buildinfo = emptyBuildInfo{
cppOptions = ["-DGHC_PATHS_GHC_PKG=" ++ show c_ghc_pkg,
"-DGHC_PATHS_GHC=" ++ show c_ghc,
"-DGHC_PATHS_LIBDIR=" ++ show libdir,
"-DGHC_PATHS_DOCDIR=" ++ show docdir ]
}
About your problem with wrong path, try to run stack --no-system-ghc ghci. If it still shows "/usr/bin/ghc-7.10.3" for GHC paths, then I suspect that you had GHC there when you compiled ghc-paths for GHC-7.10.3, and as stack is quite good in not rebuilding stuff, the old version of ghc-paths is still there. I don't know a way to rebuild a package in a snapshot, other then whiping ~/.stack and starting over; which might be a good idea. if you changed you global GHC stuff.
There is a related issue: Stop using system-ghc silently.
Is it possible to use stack with an already installed ghc without stack installing a local copy of ghc or cabal?
Yes. If the ghc in PATH is of right version for the selected snapshot, stack will happily use it.
% ghc --version
The Glorious Glasgow Haskell Compilation System, version 7.8.4
% stack --resolver=lts-2.22 install packdeps
Run from outside a project, using implicit global project config
Using resolver: lts-2.22 specified on command line
packdeps-0.4.1: unregistering
packdeps-0.4.2: download
...
% stack --resolver=nightly-2015-12-25 install packdeps
Run from outside a project, using implicit global project config
Using resolver: nightly-2015-12-25 specified on command line
Compiler version mismatched, found ghc-7.8.4 (x86_64), but expected minor version match with ghc-7.10.3 (x86_64) (based on resolver setting in /Users/phadej/.stack/global/stack.yaml).
Try running "stack setup" to install the correct GHC into /Users/phadej/.stack/programs/x86_64-osx/
You can also skip ghc check --skip-ghc-check:
% stack --resolver=nightly-2015-12-25 --skip-ghc-check install packdeps
Run from outside a project, using implicit global project config
Using resolver: nightly-2015-12-25 specified on command line
split-0.2.2: configure
...
but that might be a bad idea