How to direct cabal to use an alternative ghc version, ala stack?

Hi all, How do I direct cabal to use an alternative (i.e. - not my system’s default) version of ghc, which I’ve installed, via stack? I tried this: stack exec cabal install ... but got this: cabal: Use of GHC's environment variable GHC_PACKAGE_PATH is incompatible with Cabal. Use the flag --package-db to specify a package database (it can be used multiple times). Thanks, -db

Hi,
On 3 September 2015 at 02:37, David Banas
Hi all,
How do I direct cabal to use an alternative (i.e. - not my system’s default) version of ghc, which I’ve installed, via stack?
Try 'cabal install -w /path/to/ghc foo'.

On 03/09/15 04:12, Mikhail Glushenkov wrote:
Hi,
On 3 September 2015 at 02:37, David Banas
wrote: Hi all,
How do I direct cabal to use an alternative (i.e. - not my system’s default) version of ghc, which I’ve installed, via stack?
Try 'cabal install -w /path/to/ghc foo'.
Or simply add the path to ghc to PATH, as in PATH=$HOME/.stack/programs/x86_64-linux/ghc-$VERSION/bin:$PATH

On Thu, Sep 3, 2015 at 3:37 AM, David Banas
Hi all,
How do I direct cabal to use an alternative (i.e. - not my system’s default) version of ghc, which I’ve installed, via stack?
I tried this:
stack exec cabal install ...
but got this:
cabal: Use of GHC's environment variable GHC_PACKAGE_PATH is incompatible with Cabal. Use the flag --package-db to specify a package database (it can be used multiple times).
Thanks, -db
_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
We have a flag to working better with cabal, you can try: stack exec --no-ghc-package-path -- cabal install I'm under the impression that there are changes planned to cabal (possibly already implemented but not released) that will allow it to function nicely with the GHC_PACKAGE_PATH environment variable, but I'm uncertain if that's true. Michael

Thanks to all, whom replied.
I found that a simple “stack install …” worked perfectly, as an alternative to “cabal install ...". Stack seems to have honored all the “cabal …” things I did in setting up my sandbox, including all my “cabal sandbox —add-source …” commands (5 in all). And, of course, it used the back-rev’d version of ghc I configured it (i.e. - stack) for.
That is SO neat that I can’t understand why it’s not a featured item in the Stack documentation.
Thanks, Stack crew!
-db
On Sep 2, 2015, at 8:59 PM, Michael Snoyman
On Thu, Sep 3, 2015 at 3:37 AM, David Banas
wrote: Hi all, How do I direct cabal to use an alternative (i.e. - not my system’s default) version of ghc, which I’ve installed, via stack?
I tried this:
stack exec cabal install ...
but got this:
cabal: Use of GHC's environment variable GHC_PACKAGE_PATH is incompatible with Cabal. Use the flag --package-db to specify a package database (it can be used multiple times).
Thanks, -db
_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
We have a flag to working better with cabal, you can try:
stack exec --no-ghc-package-path -- cabal install
I'm under the impression that there are changes planned to cabal (possibly already implemented but not released) that will allow it to function nicely with the GHC_PACKAGE_PATH environment variable, but I'm uncertain if that's true.
Michael

I'm glad it worked, but I don't think it's doing what you think it's doing.
stack intentionally ignores cabal sandbox settings and the like so that the
tools don't step on each others' toes. I'm not sure what --add-source you
were using, but it's very unlikely that stack picked it up.
I am now quite curious what the problem was and how stack ended up just
working for this.
On Thu, Sep 3, 2015 at 3:32 PM, David Banas
Thanks to all, whom replied.
I found that a simple “stack install …” worked perfectly, as an alternative to “cabal install ...". Stack seems to have honored all the “cabal …” things I did in setting up my sandbox, including all my “cabal sandbox —add-source …” commands (5 in all). And, of course, it used the back-rev’d version of ghc I configured it (i.e. - stack) for.
That is SO neat that I can’t understand why it’s not a featured item in the Stack documentation. Thanks, Stack crew!
-db
On Sep 2, 2015, at 8:59 PM, Michael Snoyman
wrote: On Thu, Sep 3, 2015 at 3:37 AM, David Banas
wrote: Hi all,
How do I direct cabal to use an alternative (i.e. - not my system’s default) version of ghc, which I’ve installed, via stack?
I tried this:
stack exec cabal install ...
but got this:
cabal: Use of GHC's environment variable GHC_PACKAGE_PATH is incompatible with Cabal. Use the flag --package-db to specify a package database (it can be used multiple times).
Thanks, -db
_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
We have a flag to working better with cabal, you can try:
stack exec --no-ghc-package-path -- cabal install
I'm under the impression that there are changes planned to cabal (possibly already implemented but not released) that will allow it to function nicely with the GHC_PACKAGE_PATH environment variable, but I'm uncertain if that's true.
Michael

Hmm…is it possible that the packages entries in my stack.yaml file:
flags: {}
packages:
- '.'
- circat/
- hermit/
- hermit/examples/HIW13/second/plugin/
- hermit/optimizations/pretty/hermit-pretty/
- hermit-extras/
- kure/
- lambda-ccc/
- netlist/netlist/
- netlist/netlist-to-verilog/
- netlist/netlist-to-vhdl/
- netlist/verilog/
extra-deps:
- applicative-numbers-0.1.3
- marked-pretty-0.1
- ty-0.1.5
- type-unary-0.2.19
resolver: lts-2.22
are what guided stack down the right path, re: mimicking the effect of my “cabal sandbox —add-source …” commands?
And that the version constraints in the “lts-2.22” cabal.config just happened to be what I needed for this project?
-db
On Sep 3, 2015, at 6:25 AM, Michael Snoyman
I'm glad it worked, but I don't think it's doing what you think it's doing. stack intentionally ignores cabal sandbox settings and the like so that the tools don't step on each others' toes. I'm not sure what --add-source you were using, but it's very unlikely that stack picked it up.
I am now quite curious what the problem was and how stack ended up just working for this.
On Thu, Sep 3, 2015 at 3:32 PM, David Banas
wrote: Thanks to all, whom replied. I found that a simple “stack install …” worked perfectly, as an alternative to “cabal install ...". Stack seems to have honored all the “cabal …” things I did in setting up my sandbox, including all my “cabal sandbox —add-source …” commands (5 in all). And, of course, it used the back-rev’d version of ghc I configured it (i.e. - stack) for.
That is SO neat that I can’t understand why it’s not a featured item in the Stack documentation. Thanks, Stack crew!
-db
On Sep 2, 2015, at 8:59 PM, Michael Snoyman
wrote: On Thu, Sep 3, 2015 at 3:37 AM, David Banas
wrote: Hi all, How do I direct cabal to use an alternative (i.e. - not my system’s default) version of ghc, which I’ve installed, via stack?
I tried this:
stack exec cabal install ...
but got this:
cabal: Use of GHC's environment variable GHC_PACKAGE_PATH is incompatible with Cabal. Use the flag --package-db to specify a package database (it can be used multiple times).
Thanks, -db
_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
We have a flag to working better with cabal, you can try:
stack exec --no-ghc-package-path -- cabal install
I'm under the impression that there are changes planned to cabal (possibly already implemented but not released) that will allow it to function nicely with the GHC_PACKAGE_PATH environment variable, but I'm uncertain if that's true.
Michael

Yup, that would do it.
On Thu, Sep 3, 2015, 5:17 PM David Banas
Hmm…is it possible that the *packages* entries in my *stack.yaml *file:
flags: {} packages: - '.' - circat/ - hermit/ - hermit/examples/HIW13/second/plugin/ - hermit/optimizations/pretty/hermit-pretty/ - hermit-extras/ - kure/ - lambda-ccc/ - netlist/netlist/ - netlist/netlist-to-verilog/ - netlist/netlist-to-vhdl/ - netlist/verilog/ extra-deps: - applicative-numbers-0.1.3 - marked-pretty-0.1 - ty-0.1.5 - type-unary-0.2.19 resolver: lts-2.22
are what guided stack down the right path, re: mimicking the effect of my “cabal sandbox —add-source …” commands?
And that the version constraints in the “lts-2.22” *cabal.config* just happened to be what I needed for this project?
-db
On Sep 3, 2015, at 6:25 AM, Michael Snoyman
wrote: I'm glad it worked, but I don't think it's doing what you think it's doing. stack intentionally ignores cabal sandbox settings and the like so that the tools don't step on each others' toes. I'm not sure what --add-source you were using, but it's very unlikely that stack picked it up.
I am now quite curious what the problem was and how stack ended up just working for this.
On Thu, Sep 3, 2015 at 3:32 PM, David Banas
wrote: Thanks to all, whom replied.
I found that a simple “stack install …” worked perfectly, as an alternative to “cabal install ...". Stack seems to have honored all the “cabal …” things I did in setting up my sandbox, including all my “cabal sandbox —add-source …” commands (5 in all). And, of course, it used the back-rev’d version of ghc I configured it (i.e. - stack) for.
That is SO neat that I can’t understand why it’s not a featured item in the Stack documentation. Thanks, Stack crew!
-db
On Sep 2, 2015, at 8:59 PM, Michael Snoyman
wrote: On Thu, Sep 3, 2015 at 3:37 AM, David Banas
wrote: Hi all,
How do I direct cabal to use an alternative (i.e. - not my system’s default) version of ghc, which I’ve installed, via stack?
I tried this:
stack exec cabal install ...
but got this:
cabal: Use of GHC's environment variable GHC_PACKAGE_PATH is incompatible with Cabal. Use the flag --package-db to specify a package database (it can be used multiple times).
Thanks, -db
_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
We have a flag to working better with cabal, you can try:
stack exec --no-ghc-package-path -- cabal install
I'm under the impression that there are changes planned to cabal (possibly already implemented but not released) that will allow it to function nicely with the GHC_PACKAGE_PATH environment variable, but I'm uncertain if that's true.
Michael

If I had to guess, I'd say there's a directory structure like:
/project
/foo
/bar
/baz
And stack found all the packages in those subdirs. It just happened to
be that those were the exact ones that were add-source'd.
But this is just a guess, of course.
Erik
On 3 September 2015 at 15:25, Michael Snoyman
I'm glad it worked, but I don't think it's doing what you think it's doing. stack intentionally ignores cabal sandbox settings and the like so that the tools don't step on each others' toes. I'm not sure what --add-source you were using, but it's very unlikely that stack picked it up.
I am now quite curious what the problem was and how stack ended up just working for this.
On Thu, Sep 3, 2015 at 3:32 PM, David Banas
wrote: Thanks to all, whom replied.
I found that a simple “stack install …” worked perfectly, as an alternative to “cabal install ...". Stack seems to have honored all the “cabal …” things I did in setting up my sandbox, including all my “cabal sandbox —add-source …” commands (5 in all). And, of course, it used the back-rev’d version of ghc I configured it (i.e. - stack) for.
That is SO neat that I can’t understand why it’s not a featured item in the Stack documentation. Thanks, Stack crew!
-db
On Sep 2, 2015, at 8:59 PM, Michael Snoyman
wrote: On Thu, Sep 3, 2015 at 3:37 AM, David Banas
wrote: Hi all,
How do I direct cabal to use an alternative (i.e. - not my system’s default) version of ghc, which I’ve installed, via stack?
I tried this:
stack exec cabal install ...
but got this:
cabal: Use of GHC's environment variable GHC_PACKAGE_PATH is incompatible with Cabal. Use the flag --package-db to specify a package database (it can be used multiple times).
Thanks, -db
_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
We have a flag to working better with cabal, you can try:
stack exec --no-ghc-package-path -- cabal install
I'm under the impression that there are changes planned to cabal (possibly already implemented but not released) that will allow it to function nicely with the GHC_PACKAGE_PATH environment variable, but I'm uncertain if that's true.
Michael
_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
participants (5)
-
David Banas
-
Erik Hesselink
-
Michael Snoyman
-
Mikhail Glushenkov
-
Roman Cheplyaka