Ah, I see. I still don't understand what went wrong in this particular case, but at least it makes sense that there's a difference between `-package-db` and `cabal exec`.
I'll leave it at that.
Thanks!
/ Emil
Den 2017-08-04 kl. 18:45, skrev Brandon Allbery:
GHC_PACKAGE_PATH is the only one of those that it knows about. And the
difference is that --package-db appends to the package database path,
whereas GHC_PACKAGE_PATH sets the entire path. You would need an additional
option to override the *user* entry on the standard package db path with
that of the sandbox, to be compatible with how sandboxes work using only
command line options.
On Friday, August 4, 2017, Emil Axelsson <78emil@gmail.com> wrote:
I guess I get your point in the general case with various tools working
together. But in this case, only ghci is used, and it seems that it gets
some information from the variables `CABAL_SANDBOX_CONFIG`,
`CABAL_SANDBOX_PACKAGE_PATH` and `GHC_PACKAGE_PATH` (set by `cabal exec`)
that it doesn't get from the flag `-package-db`.
At least I find that a little strange.
/ Emil
Den 2017-08-04 kl. 16:58, skrev Brandon Allbery:
ghc including ghci does not know about sandboxes. At all. That is what
cabal/stack exec is for; it runs a command inside the sandbox.
There are sandboxing mechanisms that don't require this, but they require
your shell dotfiles to be set up in a way almost nobody does these days
(proper separation of environment variables; otherwise you get things like
the sandbox's package database, but the wrong $PATH). hsenv used to work
that way.
On Friday, August 4, 2017, Emil Axelsson <78emil@gmail.com
<javascript:_e(%7B%7D,'cvml','78emil@gmail.com ');>> wrote:
Thanks for your reply! But I actually don't want `cabal repl`. The bigger
picture is explained here:
http://fun-discoveries.blogspot.com/2017/08/building-haskell
-projects-with-ghc.html
Towards the end of that post I suggest using `cabal exec` to integrate
with a Cabal sandbox; however, as Daniel Trstenjak pointed out, that
shouldn't be needed since `cabal-cargs` already sets the `-package-db`
flag
for GHC.
So my question is why `cabal exec` is needed (in this particular case)
even though `-package-db` is given?
I know `cabal exec` sets a few environment variables
(`CABAL_SANDBOX_CONFIG`, `CABAL_SANDBOX_PACKAGE_PATH` and
`GHC_PACKAGE_PATH`). I've checked that these are all set correctly, so
Cabal seems to be doing its job. But it's not clear why ghci gets
confused
when these variables are not set (and `-package-db` is given), but not
when
the variables are set.
Cheers
/ Emil
Den 2017-08-04 kl. 15:31, skrev nek0:
Hi Emil,
Haskell-Cafe mailing list
What you want is hidden behind the `cabal repl` command, which starts
ghci with the package-db of the sandbox.
Greetings,
nek0
On 4.8.2017 13:41, Emil Axelsson wrote:
Hi!
I have a small file Test.hs alone in a directory:
{-# LANGUAGE DeriveGeneric #-}
module Test where
import Data.Hashable
import Data.Scientific
import GHC.Generics
data Sc = Sc Scientific deriving (Generic)
instance Hashable Sc
To be able to load this file, I set up a Cabal sandbox:
$ ghc --numeric-version
8.0.2
$ cabal --numeric-version
1.24.0.2
$ cabal sandbox init
...
$ cabal install hashable-1.2.6.0 scientific
...
(Note: not the latest version of hashable.)
Now, if I try to run GHCi and point it to the sandbox' package database
I get this error:
$ ghci
-package-db=.cabal-sandbox/x86_64-linux-ghc-8.0.2-packages. conf.d
Test.hs GHCi, version 8.0.2: http://www.haskell.org/ghc/ :? for help
[1 of 1] Compiling Test ( Test.hs, interpreted )
Test.hs:12:14: error:
• No instance for (Hashable Scientific)
arising from a use of
‘hashable-1.2.6.1:Data.Hashable.Class.$dmhashWithSalt’
• In the expression:
hashable-1.2.6.1:Data.Hashable.Class.$dmhashWithSalt @Sc
In an equation for ‘hashWithSalt’:
hashWithSalt
= hashable-1.2.6.1:Data.Hashable
.Class.$dmhashWithSalt
@Sc
In the instance declaration for ‘Hashable Sc’
Somehow it mixes in version 1.2.6.1 of hashable, even though this
package isn't installed (neither in the sandbox nor the global
database).
It turns out that wrapping the command in `cabal exec` fixes the
problem:
$ cabal exec -- ghci
-package-db=.cabal-sandbox/x86_64-linux-ghc-8.0.2-packages. conf.d
Test.hs
GHCi, version 8.0.2: http://www.haskell.org/ghc/ :? for help
[1 of 1] Compiling Test ( Test.hs, interpreted )
Ok, modules loaded: Test.
*Test>
Any idea what's going on?
/ Emil
_______________________________________________
Haskell-Cafe mailing list
To (un)subscribe, modify options or view archives go to:
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-caf e
Only members subscribed via the mailman list are allowed to post.
_______________________________________________
To (un)subscribe, modify options or view archives go to:
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-caf e
Only members subscribed via the mailman list are allowed to post.