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.
Related
I'm getting an error that says the module doesn't exist when I try to runhaskell. It's odd because I try to install it first and says its up to date. Any idea how to fix this?
You could try creating the package environment in the local directory that holds your project, like this:
c:\Users\...\ex1haskell> cabal install --lib --package-env . QuickCheck
This should create a file of the form .ghc.environment.xxx in ex1haskell, which hopefully should be picked up by runhaskell/ghci/ghc invocations.
In ghci sessions, a sign that the environment is being picked up is the following message while starting:
Loaded package environment from ...
When the --package-env location is not given explicitly, a default location is used. According to the docs:
By default, it is writing to the global environment in
~/.ghc/$ARCH-$OS-$GHCVER/environments/default. v2-install provides the
--package-env flag to control which of these environments is modified.
But it seems that runhaskell is having problems to find the environment file in that default location.
Note. When creating a package environment, it's possible to specify multiple packages simultaneously, like this:
cabal install --lib --package-env . QuickCheck random aeson transformers
Also, package environments are just text files, so local environments can be deleted and recreated at will. The actual package binaries reside elsewhere and can potentially be reused by cabal.
A Common Environment
It is hard to debug if/when the actual tooling differs so let's first get a unified setup. I'll use docker to get GHC 8 and Cabal 3.x:
docker run --rm -it haskell bash
Understand that this isn't arbitrary or even preemptive. What you have shown - cabal install --lib ... and runhaskell ... does work for sane tool installations. You might have a bad installation or an old version of a tool that has different behavior.
Running a single file with runhaskell
Now we need a project:
root#8a934c302dba:/# mkdir Ex1
root#8a934c302dba:/# cd Ex1
root#8a934c302dba:/Ex1# cat <<EOF >Main.hs
> import Test.QuickCheck
>
> main :: IO ()
> main = print =<< (generate arbitrary :: IO Int)
> EOF
And test failure:
root#8a934c302dba:/Ex1# runhaskell Main.hs
Main.hs:1:1: error:
Could not find module `Test.QuickCheck'
Use -v (or `:set -v` in ghci) to see a list of the files searched for.
|
1 | import Test.QuickCheck
And install the library:
root#8a934c302dba:/Ex1# cabal update && cabal install --lib QuickCheck
And successful run:
root#8a934c302dba:/Ex1# runhaskell Main.hs
15
So my comment above was wrong - we don't need to explicitly list the package as it is already exposed after installation.
With the release of cabal-3, the packages from Hackage are installed in a new location that the compiler ghc and ghc-pkg know nothing about.
In other words, packages are installed but not registered for ghc. Ghci, ghc, ghc-pkg cannot work.
For example,
cabal install safe --lib
Create file t1.hs
import Safe
t1 = tailMay [1,2,3]
Let's try:
> ghci t1.hs
GHCi, version 8.10.2: https://www.haskell.org/ghc/:? for help
[1 of 1] Compiling Main (t1.hs, interpreted)
t1.hs: 1: 1: error:
Could not find module `Safe '
Use -v (or `: set -v` in ghci) to see a list of the files searched for.
|
1 | import Safe
| ^^^^^^^^^^^
Failed, no modules loaded.
This bug is described here
https://github.com/haskell/cabal/issues/6262
and here
https://gitlab.haskell.org/ghc/ghc/-/issues/17341
I use as a temporary solution setting a system variable
GHC_PACKAGE_PATH=C:\Users\me\AppData\Roaming\cabal\store\ghc-8.10.2\package.db;
(Windwos 10, haskell-dev by chocolatey)
via
On Windows, packages installed with cabal seem to be unavailable in ghc/ghci
but with updates I will have to manually change this system variable.
Are there any more elegant solutions to this problem?
P.S. Unfortunately, this solution (via GHC's environment variable GHC_PACKAGE_PATH) is incompatible with Cabal :(
https://github.com/haskell/cabal/issues/1944
One way to achieve this is to use the --env flag to make the libraries available to GHC whenever you are in the current directory:
~ $ mkdir /tmp/foo
~ $ cd /tmp/foo
/tmp/foo $ cabal install safe --lib --env .
Resolving dependencies...
Build profile: -w ghc-8.8.3 -O1
In order, the following will be built (use -v for more details):
- safe-0.3.19 (lib) (requires build)
Configuring library for safe-0.3.19..
Preprocessing library for safe-0.3.19..
Building library for safe-0.3.19..
…
> Installing library in /home/jojo/.cabal/store/ghc-8.8.3/incoming/new-4056/home/jojo/.cabal/store/ghc-8.8.3/safe-0.3.19-92fbaef88124b4508ce447f6245bc793f7a1748247ae68d10e449150df1069af/lib
t1.hs
/tmp/foo $ cat > t1.hs
import Safe
t1 = tailMay [1,2,3]
/tmp/foo $ ls -a
. .. .ghc.environment.x86_64-linux-8.8.3 t1.hs
/tmp/foo $ ghci t1.hs
GHCi, version 8.8.3: https://www.haskell.org/ghc/ :? for help
Loaded package environment from /tmp/foo/.ghc.environment.x86_64-linux-8.8.3
[1 of 1] Compiling Main ( t1.hs, interpreted )
Ok, one module loaded.
*Main>
Note that you probably shouldn’t do this in a directory where you actually have a foo.cabal file. See the documentation of cabal v2-install for details.
Working with GHC_ENVIRONMENT is better:
setx GHC_ENVIRONMENT C:\Users\me\.ghc\x86_64-mingw32-8.10.2\environments\default
it helps for ghc and ghci.
After, in C:\Users\me\AppData\Roaming\cabal\config we should add
package-db: C:\Users\me\AppData\Roaming\cabal\store\ghc-8.10.2\package.db
it helps for cabal.
Unfortunately, ghc-pkg still has problem and works with such flag:
ghc-pkg list --user-package-db="C:\Users\me\AppData\Roaming\cabal\store\ghc-8.10.2\package.db"
For Linux the steps are similar.
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 created a new project and, as you can see, it even downloaded a brand new build plan for lts-7.4, which as you can see uses ghc-8.0.1.
But when running stack ghci, it built the project with GHC 7.10, and dropped me in a 7.10 ghci shell.
dario#curie /tmp> stack new foo
Downloading template "new-template" to create project "foo" in foo/ ...
Looking for .cabal or package.yaml files to use to init the project.
Using cabal packages:
- foo/foo.cabal
Selecting the best among 9 snapshots...
Downloaded lts-7.4 build plan.
* Matches lts-7.4
Selected resolver: lts-7.4
Initialising configuration using resolver: lts-7.4
Total number of user packages considered: 1
Writing configuration to file: foo/stack.yaml
All done.
dario#curie /tmp> cd foo
dario#curie /t/foo> stack ghci
foo-0.1.0.0: configure
Configuring foo-0.1.0.0...
foo-0.1.0.0: build
Preprocessing library foo-0.1.0.0...
[1 of 1] Compiling Lib ( src/Lib.hs, .stack-work/dist/x86_64-linux/Cabal-1.22.5.0/build/Lib.o )
In-place registering foo-0.1.0.0...
Preprocessing executable 'foo-exe' for foo-0.1.0.0...
[1 of 1] Compiling Main ( app/Main.hs, .stack-work/dist/x86_64-linux/Cabal-1.22.5.0/build/foo-exe/foo-exe-tmp/Main.o )
Linking .stack-work/dist/x86_64-linux/Cabal-1.22.5.0/build/foo-exe/foo-exe ...
foo-0.1.0.0: copy/register
Installing library in
/tmp/foo/.stack-work/install/x86_64-linux/lts-7.4/7.10.3/lib/x86_64-linux-ghc-7.10.3/foo-0.1.0.0-6bylsnNRJPuHxByS3dKqs5
Installing executable(s) in
/tmp/foo/.stack-work/install/x86_64-linux/lts-7.4/7.10.3/bin
Registering foo-0.1.0.0...
The following GHC options are incompatible with GHCi and have not been passed to it: -threaded
Using main module: 1. Package `foo' component exe:foo-exe with main-is file: /tmp/foo/app/Main.hs
Configuring GHCi with the following packages: foo
GHCi, version 7.10.3: http://www.haskell.org/ghc/ :? for help
[1 of 1] Compiling Lib ( /tmp/foo/src/Lib.hs, interpreted )
Ok, modules loaded: Lib.
[2 of 2] Compiling Main ( /tmp/foo/app/Main.hs, interpreted )
Ok, modules loaded: Lib, Main.
>
I always relied on the assumption that for every stackage snapshot, stack would use only one version of GHC, am I wrong?
I don't have system-ghc: true in my config, and the faq doesn't mention many other alternatives
This is the output of stack path:
dario#curie /t/foo> stack path
stack-root: /home/dario/.stack
project-root: /tmp/foo
config-location: /tmp/foo/stack.yaml
bin-path: /home/dario/.stack/snapshots/x86_64-linux/lts-7.4/7.10.3/bin:/home/dario/.stack/programs/x86_64-linux/ghc-8.0.1/bin:/home/dario/Applications/bin:/home/dario/.rbenv/shims:/home/dario/.cabal/bin:/home/dario/.nix-profile/bin:/home/dario/.nix-profile/sbin:/home/dario/.sdkman/candidates/grails/current/bi n:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/snap/bin:/usr/lib/jvm/java-8-oracle/bin:/usr/lib/jvm/java-8-oracle/db/bin:/usr/lib/jvm/java-8-oracle/jre/bin:/home/dario/.local/bin:/home/dario/.nix-profile/bin
programs: /home/dario/.stack/programs/x86_64-linux
compiler-exe: /usr/bin/ghc
compiler-bin: /usr/bin
local-bin: /home/dario/.local/bin
extra-include-dirs:
extra-library-dirs:
snapshot-pkg-db: /home/dario/.stack/snapshots/x86_64-linux/lts-7.4/7.10.3/pkgdb
local-pkg-db: /tmp/foo/.stack-work/install/x86_64-linux/lts-7.4/7.10.3/pkgdb
global-pkg-db: /var/lib/ghc/package.conf.d
ghc-package-path: /tmp/foo/.stack-work/install/x86_64-linux/lts-7.4/7.10.3/pkgdb:/home/dario/.stack/snapshots/x86_64-linux/lts-7.4/7.10.3/pkgdb:/var/lib/ghc/package.conf.d
snapshot-install-root: /home/dario/.stack/snapshots/x86_64-linux/lts-7.4/7.10.3
local-install-root: /tmp/foo/.stack-work/install/x86_64-linux/lts-7.4/7.10.3
snapshot-doc-root: /home/dario/.stack/snapshots/x86_64-linux/lts-7.4/7.10.3/doc
local-doc-root: /tmp/foo/.stack-work/install/x86_64-linux/lts-7.4/7.10.3/doc
dist-dir: .stack-work/dist/x86_64-linux/Cabal-1.22.5.0
local-hpc-root: /tmp/foo/.stack-work/install/x86_64-linux/lts-7.4/7.10.3/hpc
local-bin-path: /home/dario/.local/bin
ghc-paths: /home/dario/.stack/programs/x86_64-linux
dario#curie /t/foo> echo $PATH
/home/dario/Applications/bin /home/dario/.rbenv/shims /home/dario/.cabal/bin /home/dario/.nix-profile/bin /home/dario/.nix-profile/sbin /home/dario/.sdkman/candidates/grails/current/bin /usr/local/sbin /usr/local/bin /usr/sbin /usr/bin /sbin /bin /usr/games /usr/local/games /snap/bin /usr/lib/jvm/java-8-oracle/bin /usr/lib/jvm/java-8-oracle/db/bin /usr/lib/jvm/java-8-oracle/jre/bin /home/dario/.local/bin /home/dario/.nix-profile/bin
I rely on the lts determining the version of ghc in use also for CI, so it's a bit worrying if my assumption doesn't hold (anymore?)
(I'm running stack Version 1.2.0 x86_64 hpack-0.14.0)
This is the output of stack setup
dario#curie /t/foo> stack setup
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
I realized that this was due to the faulty way in which I "worked around" this issue:
https://github.com/commercialhaskell/stack/issues/2712
I might open it as another bug report, but it's definitely less important/interesting than fixing #2712
I have following problem with ghc-mod which prevents me from using ide for some files in a yesod app project.
I install template app as follows:
/tmp$ stack new demo yesod-sqlite && cd demo
/tmp/demo$ stack setup && stack build && stack install ghc-mod
Which yields following stack.yaml (commented lines removed):
resolver: lts-5.6
packages:
- '.'
extra-deps: []
flags: {}
extra-package-dbs: []
And this is a demo.cabal: http://pastebin.com/i4n1TR6W.
Then, running stack exec -- ghc-mod check app/main.hs does not produce errors, but stack exec -- ghc-mod check app/devel.hs has this to say:
app/devel.hs:2:1:Failed to load interface for ‘Application’It is a member of the hidden package ‘demo-0.0.0’.Perhaps you need to add ‘demo’ to the build-depends in your .cabal file.
So the ghc-mod somehow thinks this package is itself hidden? But any other place where project's files are imported by another checks fine, and the application builds and works successfully. The only specifics about this file is using PackageImports language extension:
{-# LANGUAGE PackageImports #-}
import "demo" Application (develMain)
I tried googling the error message but it seems to only come up with regard to external packages and not the one being debugged.
These two files devel.hs and DevelMain.hs are quite special: they are marked as a module of demo in .cabal but they are importing demo as a compiled package, i.e. recursive dependency.
They are not exposed from library demo nor imported anywhere else so won't get compiled when you run stack build, but when you run ghc-mod check on them, they are interpreted in the context of the current project, therefore the recursive dependency will be an issue.
The only purpose of these two otherwise meaningless files is to debug your yesod website in ghci, as the comment in DevelMain.hs stated:
-- | Running your app inside GHCi.
--
-- To start up GHCi for usage with Yesod, first make sure you are in dev mode:
--
-- > cabal configure -fdev
--
-- Note that #yesod devel# automatically sets the dev flag.
-- Now launch the repl:
--
-- > cabal repl --ghc-options="-O0 -fobject-code"
--
-- To start your app, run:
--
-- > :l DevelMain
-- > DevelMain.update
--
-- You can also call #DevelMain.shutdown# to stop the app
--
-- You will need to add the foreign-store package to your .cabal file.
-- It is very light-weight.
--
-- If you don't use cabal repl, you will need
-- to run the following in GHCi or to add it to
-- your .ghci file.
--
-- :set -DDEVELOPMENT
--
-- There is more information about this approach,
-- on the wiki: https://github.com/yesodweb/yesod/wiki/ghci
cabal repl and stack ghci will compile the project beforehand so these two files won't cause any error there.