LTS-10.* missing build-depends suggestion

Rick Owens

25 Jan 2018 25 Jan '18

1:12 a.m.

Dear Haskell Café, I am a long-time Haskell developer with a proliferation of private projects. I typically make very heavy use of stack and LTS. Today, I tried to bootstrap my first project using LTS-10.* (with GHC-8.2.2) and I ran into an interesting problem (for me). In the past, with lts-9.* and below, when I started cranking on some code and writing a bunch of imports:

...

import Control.Monad.Trans.Class (MonadTrans) import Data.Map (Map)

I would try to build first without updating the cabal file build-depends, and I would get something like the following error messages:

...

/path/to/Module.hs:48:1: error: Failed to load interface for ‘Data.Map’ It is a member of the hidden package ‘containers-0.5.7.1’. Perhaps you need to add ‘containers’ to the build-depends in your .cabal file. Use -v to see a list of the files searched for.

/path/to/Module.hs:21:1: error: Failed to load interface for ‘Control.Monad.Trans.Class’ It is a member of the hidden package ‘transformers-0.5.2.0’. Perhaps you need to add ‘transformers’ to the build-depends in your .cabal file. Use -v to see a list of the files searched for.

This was good because the error contained a suggested solution which contained the missing package, and I could sort of lazily add the build-depends I needed without having to memorize a (Module -> Package) mapping. I even had developer tooling to do it automatically. With lts-10.*, however, the analogous error message looks like this:

...

/path/to/Module.hs:9:1: error: Could not find module ‘Data.DoubleWord’ Use -v to see a list of the files searched for. | 9 | import Data.DoubleWord (Word256(Word256), Word128(Word128)) | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

I am wondering, is there a way to bring back the solution suggestion? Not having access to it has made me realize how heavily I was using that feature. What do others think about this missing bit of supplemental error information? Thanks, -Rick Owens

Attachments:

attachment.html (text/html — 2.7 KB)

Show replies by date

Dan Burton

25 Jan 25 Jan

2:02 a.m.

I believe the particular feature you are talking about is a feature of GHC. Whether a suggestion is show or not merely depends on whether GHC sees the package in question in its package database(s). If you are using stack, then you can look at one of your LTS 9 projects, and run stack exec -- ghc-pkg list In order to see the list of installed packages. (I think something like `cabal exec ghc-pkg list` should do the same for a cabal project.) Identify the packages you tend to use, go into one of your LTS 10 projects, and `stack install pkg1 pkg2 ...` Note that with stack, each minor version of LTS has its own package database, so packages locally installed into lts-10.1 will not necessarily be available in your local instance of lts-10.2. Repeat stack install to taste. tl;dr the trick is to set up your package database so that GHC knows what to suggest for you -- Dan Burton On Wed, Jan 24, 2018 at 5:12 PM, Rick Owens wrote:

...

Dear Haskell Café,

I am a long-time Haskell developer with a proliferation of private projects. I typically make very heavy use of stack and LTS. Today, I tried to bootstrap my first project using LTS-10.* (with GHC-8.2.2) and I ran into an interesting problem (for me).

In the past, with lts-9.* and below, when I started cranking on some code and writing a bunch of imports:

...
import Control.Monad.Trans.Class (MonadTrans) import Data.Map (Map)

I would try to build first without updating the cabal file build-depends, and I would get something like the following error messages:

...
/path/to/Module.hs:48:1: error: Failed to load interface for ‘Data.Map’ It is a member of the hidden package ‘containers-0.5.7.1’. Perhaps you need to add ‘containers’ to the build-depends in your .cabal file. Use -v to see a list of the files searched for.

/path/to/Module.hs:21:1: error: Failed to load interface for ‘Control.Monad.Trans.Class’ It is a member of the hidden package ‘transformers-0.5.2.0’. Perhaps you need to add ‘transformers’ to the build-depends in your .cabal file. Use -v to see a list of the files searched for.

This was good because the error contained a suggested solution which contained the missing package, and I could sort of lazily add the build-depends I needed without having to memorize a (Module -> Package) mapping. I even had developer tooling to do it automatically.

With lts-10.*, however, the analogous error message looks like this:

...
/path/to/Module.hs:9:1: error: Could not find module ‘Data.DoubleWord’ Use -v to see a list of the files searched for. | 9 | import Data.DoubleWord (Word256(Word256), Word128(Word128)) | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

I am wondering, is there a way to bring back the solution suggestion? Not having access to it has made me realize how heavily I was using that feature. What do others think about this missing bit of supplemental error information?

Thanks,

-Rick Owens

_______________________________________________ Haskell-Cafe mailing list To (un)subscribe, modify options or view archives go to: http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe Only members subscribed via the mailman list are allowed to post.

Michael Snoyman

4:38 a.m.

FWIW, I've also noticed that with LTS 10/GHC 8.2.2 I no longer get the package name suggestions, even when I know I have the package installed. I don't know if it's an issue with Stack or GHC, I haven't investigated. But I can't think of something on the Stack side which would make the behavior different between GHC 8.0.2 and GHC 8.2.2. On Thu, Jan 25, 2018 at 4:02 AM, Dan Burton wrote:

...

I believe the particular feature you are talking about is a feature of GHC. Whether a suggestion is show or not merely depends on whether GHC sees the package in question in its package database(s).

If you are using stack, then you can look at one of your LTS 9 projects, and run

stack exec -- ghc-pkg list

In order to see the list of installed packages. (I think something like `cabal exec ghc-pkg list` should do the same for a cabal project.)

Identify the packages you tend to use, go into one of your LTS 10 projects, and `stack install pkg1 pkg2 ...`

Note that with stack, each minor version of LTS has its own package database, so packages locally installed into lts-10.1 will not necessarily be available in your local instance of lts-10.2. Repeat stack install to taste.

tl;dr the trick is to set up your package database so that GHC knows what to suggest for you

-- Dan Burton

On Wed, Jan 24, 2018 at 5:12 PM, Rick Owens wrote:

...
Dear Haskell Café,

I am a long-time Haskell developer with a proliferation of private projects. I typically make very heavy use of stack and LTS. Today, I tried to bootstrap my first project using LTS-10.* (with GHC-8.2.2) and I ran into an interesting problem (for me).

In the past, with lts-9.* and below, when I started cranking on some code and writing a bunch of imports:

...
import Control.Monad.Trans.Class (MonadTrans) import Data.Map (Map)

I would try to build first without updating the cabal file build-depends, and I would get something like the following error messages:

...
/path/to/Module.hs:48:1: error: Failed to load interface for ‘Data.Map’ It is a member of the hidden package ‘containers-0.5.7.1’. Perhaps you need to add ‘containers’ to the build-depends in your .cabal file. Use -v to see a list of the files searched for.

/path/to/Module.hs:21:1: error: Failed to load interface for ‘Control.Monad.Trans.Class’ It is a member of the hidden package ‘transformers-0.5.2.0’. Perhaps you need to add ‘transformers’ to the build-depends in your .cabal file. Use -v to see a list of the files searched for.

This was good because the error contained a suggested solution which contained the missing package, and I could sort of lazily add the build-depends I needed without having to memorize a (Module -> Package) mapping. I even had developer tooling to do it automatically.

With lts-10.*, however, the analogous error message looks like this:

...
/path/to/Module.hs:9:1: error: Could not find module ‘Data.DoubleWord’ Use -v to see a list of the files searched for. | 9 | import Data.DoubleWord (Word256(Word256), Word128(Word128)) | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

I am wondering, is there a way to bring back the solution suggestion? Not having access to it has made me realize how heavily I was using that feature. What do others think about this missing bit of supplemental error information?

Thanks,

-Rick Owens

_______________________________________________ Haskell-Cafe mailing list To (un)subscribe, modify options or view archives go to: http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe Only members subscribed via the mailman list are allowed to post.

_______________________________________________ Haskell-Cafe mailing list To (un)subscribe, modify options or view archives go to: http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe Only members subscribed via the mailman list are allowed to post.

Dan Burton

7:29 a.m.

Hm, you're right. Seems like a GHC thing. I've tested a simple file with "import Data.Map" on both a stack project and a cabal project -- with containers installed in ghc's main package-db, as verified via stack/cabal exec ghc-pkg list containers -- and it doesn't give the hint in either case. Taking it a step further and removing cabal/stack out of the equation... $ cat Main.hs module Main where import Data.Map main = putStrLn "It compiles" $ ghc-pkg list containers /usr/local/Cellar/ghc/8.2.2/lib/ghc-8.2.2/package.conf.d containers-0.5.10.2 $ ghc --make -hide-all-packages -package base Main.hs [1 of 1] Compiling Main ( Main.hs, Main.o ) Main.hs:2:1: error: Could not find module ‘Data.Map’ Use -v to see a list of the files searched for. | 2 | import Data.Map | ^^^^^^^^^^^^^^^ $ ghc --make -hide-all-packages -package base -package containers Main.hs [1 of 1] Compiling Main ( Main.hs, Main.o ) Linking Main ... -- Dan Burton On Wed, Jan 24, 2018 at 8:38 PM, Michael Snoyman wrote:

...

FWIW, I've also noticed that with LTS 10/GHC 8.2.2 I no longer get the package name suggestions, even when I know I have the package installed. I don't know if it's an issue with Stack or GHC, I haven't investigated. But I can't think of something on the Stack side which would make the behavior different between GHC 8.0.2 and GHC 8.2.2.

On Thu, Jan 25, 2018 at 4:02 AM, Dan Burton wrote:

...
I believe the particular feature you are talking about is a feature of GHC. Whether a suggestion is show or not merely depends on whether GHC sees the package in question in its package database(s).

If you are using stack, then you can look at one of your LTS 9 projects, and run

stack exec -- ghc-pkg list

In order to see the list of installed packages. (I think something like `cabal exec ghc-pkg list` should do the same for a cabal project.)

Identify the packages you tend to use, go into one of your LTS 10 projects, and `stack install pkg1 pkg2 ...`

Note that with stack, each minor version of LTS has its own package database, so packages locally installed into lts-10.1 will not necessarily be available in your local instance of lts-10.2. Repeat stack install to taste.

tl;dr the trick is to set up your package database so that GHC knows what to suggest for you

-- Dan Burton

On Wed, Jan 24, 2018 at 5:12 PM, Rick Owens wrote:

...
Dear Haskell Café,

I am a long-time Haskell developer with a proliferation of private projects. I typically make very heavy use of stack and LTS. Today, I tried to bootstrap my first project using LTS-10.* (with GHC-8.2.2) and I ran into an interesting problem (for me).

In the past, with lts-9.* and below, when I started cranking on some code and writing a bunch of imports:

...
import Control.Monad.Trans.Class (MonadTrans) import Data.Map (Map)

I would try to build first without updating the cabal file build-depends, and I would get something like the following error messages:

...
/path/to/Module.hs:48:1: error: Failed to load interface for ‘Data.Map’ It is a member of the hidden package ‘containers-0.5.7.1’. Perhaps you need to add ‘containers’ to the build-depends in your .cabal file. Use -v to see a list of the files searched for.

/path/to/Module.hs:21:1: error: Failed to load interface for ‘Control.Monad.Trans.Class’ It is a member of the hidden package ‘transformers-0.5.2.0’. Perhaps you need to add ‘transformers’ to the build-depends in your .cabal file. Use -v to see a list of the files searched for.

This was good because the error contained a suggested solution which contained the missing package, and I could sort of lazily add the build-depends I needed without having to memorize a (Module -> Package) mapping. I even had developer tooling to do it automatically.

With lts-10.*, however, the analogous error message looks like this:

...
/path/to/Module.hs:9:1: error: Could not find module ‘Data.DoubleWord’ Use -v to see a list of the files searched for. | 9 | import Data.DoubleWord (Word256(Word256), Word128(Word128)) | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

I am wondering, is there a way to bring back the solution suggestion? Not having access to it has made me realize how heavily I was using that feature. What do others think about this missing bit of supplemental error information?

Thanks,

-Rick Owens

_______________________________________________ Haskell-Cafe mailing list To (un)subscribe, modify options or view archives go to: http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe Only members subscribed via the mailman list are allowed to post.

_______________________________________________ Haskell-Cafe mailing list To (un)subscribe, modify options or view archives go to: http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe Only members subscribed via the mailman list are allowed to post.

Michael Snoyman

9:51 a.m.

Nice repro Dan! I hope you don't mind, I took your repro and opened a GHC Trac ticket about this: https://ghc.haskell.org/trac/ghc/ticket/14717#ticket On Thu, Jan 25, 2018 at 9:29 AM, Dan Burton wrote:

...

Hm, you're right. Seems like a GHC thing. I've tested a simple file with "import Data.Map" on both a stack project and a cabal project -- with containers installed in ghc's main package-db, as verified via stack/cabal exec ghc-pkg list containers -- and it doesn't give the hint in either case.

Taking it a step further and removing cabal/stack out of the equation...

$ cat Main.hs module Main where import Data.Map main = putStrLn "It compiles"

$ ghc-pkg list containers /usr/local/Cellar/ghc/8.2.2/lib/ghc-8.2.2/package.conf.d containers-0.5.10.2

$ ghc --make -hide-all-packages -package base Main.hs [1 of 1] Compiling Main ( Main.hs, Main.o )

Main.hs:2:1: error: Could not find module ‘Data.Map’ Use -v to see a list of the files searched for. | 2 | import Data.Map | ^^^^^^^^^^^^^^^

$ ghc --make -hide-all-packages -package base -package containers Main.hs [1 of 1] Compiling Main ( Main.hs, Main.o ) Linking Main ...

-- Dan Burton

On Wed, Jan 24, 2018 at 8:38 PM, Michael Snoyman wrote:

...
FWIW, I've also noticed that with LTS 10/GHC 8.2.2 I no longer get the package name suggestions, even when I know I have the package installed. I don't know if it's an issue with Stack or GHC, I haven't investigated. But I can't think of something on the Stack side which would make the behavior different between GHC 8.0.2 and GHC 8.2.2.

On Thu, Jan 25, 2018 at 4:02 AM, Dan Burton wrote:

...
I believe the particular feature you are talking about is a feature of GHC. Whether a suggestion is show or not merely depends on whether GHC sees the package in question in its package database(s).

If you are using stack, then you can look at one of your LTS 9 projects, and run

stack exec -- ghc-pkg list

In order to see the list of installed packages. (I think something like `cabal exec ghc-pkg list` should do the same for a cabal project.)

Identify the packages you tend to use, go into one of your LTS 10 projects, and `stack install pkg1 pkg2 ...`

Note that with stack, each minor version of LTS has its own package database, so packages locally installed into lts-10.1 will not necessarily be available in your local instance of lts-10.2. Repeat stack install to taste.

tl;dr the trick is to set up your package database so that GHC knows what to suggest for you

-- Dan Burton

On Wed, Jan 24, 2018 at 5:12 PM, Rick Owens wrote:

...
Dear Haskell Café,

I am a long-time Haskell developer with a proliferation of private projects. I typically make very heavy use of stack and LTS. Today, I tried to bootstrap my first project using LTS-10.* (with GHC-8.2.2) and I ran into an interesting problem (for me).

In the past, with lts-9.* and below, when I started cranking on some code and writing a bunch of imports:

...
import Control.Monad.Trans.Class (MonadTrans) import Data.Map (Map)

I would try to build first without updating the cabal file build-depends, and I would get something like the following error messages:

...
/path/to/Module.hs:48:1: error: Failed to load interface for ‘Data.Map’ It is a member of the hidden package ‘containers-0.5.7.1’. Perhaps you need to add ‘containers’ to the build-depends in your .cabal file. Use -v to see a list of the files searched for.

/path/to/Module.hs:21:1: error: Failed to load interface for ‘Control.Monad.Trans.Class’ It is a member of the hidden package ‘transformers-0.5.2.0’. Perhaps you need to add ‘transformers’ to the build-depends in your .cabal file. Use -v to see a list of the files searched for.

This was good because the error contained a suggested solution which contained the missing package, and I could sort of lazily add the build-depends I needed without having to memorize a (Module -> Package) mapping. I even had developer tooling to do it automatically.

With lts-10.*, however, the analogous error message looks like this:

...
/path/to/Module.hs:9:1: error: Could not find module ‘Data.DoubleWord’ Use -v to see a list of the files searched for. | 9 | import Data.DoubleWord (Word256(Word256), Word128(Word128)) | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

I am wondering, is there a way to bring back the solution suggestion? Not having access to it has made me realize how heavily I was using that feature. What do others think about this missing bit of supplemental error information?

Thanks,

-Rick Owens

_______________________________________________ Haskell-Cafe mailing list To (un)subscribe, modify options or view archives go to: http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe Only members subscribed via the mailman list are allowed to post.

_______________________________________________ Haskell-Cafe mailing list To (un)subscribe, modify options or view archives go to: http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe Only members subscribed via the mailman list are allowed to post.

Rick Owens

5:32 p.m.

Thanks for the help/info guys! On Thu, Jan 25, 2018 at 3:51 AM, Michael Snoyman wrote:

...

Nice repro Dan! I hope you don't mind, I took your repro and opened a GHC Trac ticket about this:

https://ghc.haskell.org/trac/ghc/ticket/14717#ticket

On Thu, Jan 25, 2018 at 9:29 AM, Dan Burton wrote:

...
Hm, you're right. Seems like a GHC thing. I've tested a simple file with "import Data.Map" on both a stack project and a cabal project -- with containers installed in ghc's main package-db, as verified via stack/cabal exec ghc-pkg list containers -- and it doesn't give the hint in either case.

Taking it a step further and removing cabal/stack out of the equation...

$ cat Main.hs module Main where import Data.Map main = putStrLn "It compiles"

$ ghc-pkg list containers /usr/local/Cellar/ghc/8.2.2/lib/ghc-8.2.2/package.conf.d containers-0.5.10.2

$ ghc --make -hide-all-packages -package base Main.hs [1 of 1] Compiling Main ( Main.hs, Main.o )

Main.hs:2:1: error: Could not find module ‘Data.Map’ Use -v to see a list of the files searched for. | 2 | import Data.Map | ^^^^^^^^^^^^^^^

$ ghc --make -hide-all-packages -package base -package containers Main.hs [1 of 1] Compiling Main ( Main.hs, Main.o ) Linking Main ...

-- Dan Burton

On Wed, Jan 24, 2018 at 8:38 PM, Michael Snoyman wrote:

...
FWIW, I've also noticed that with LTS 10/GHC 8.2.2 I no longer get the package name suggestions, even when I know I have the package installed. I don't know if it's an issue with Stack or GHC, I haven't investigated. But I can't think of something on the Stack side which would make the behavior different between GHC 8.0.2 and GHC 8.2.2.

On Thu, Jan 25, 2018 at 4:02 AM, Dan Burton wrote:

...
I believe the particular feature you are talking about is a feature of GHC. Whether a suggestion is show or not merely depends on whether GHC sees the package in question in its package database(s).

If you are using stack, then you can look at one of your LTS 9 projects, and run

stack exec -- ghc-pkg list

In order to see the list of installed packages. (I think something like `cabal exec ghc-pkg list` should do the same for a cabal project.)

Identify the packages you tend to use, go into one of your LTS 10 projects, and `stack install pkg1 pkg2 ...`

Note that with stack, each minor version of LTS has its own package database, so packages locally installed into lts-10.1 will not necessarily be available in your local instance of lts-10.2. Repeat stack install to taste.

tl;dr the trick is to set up your package database so that GHC knows what to suggest for you

-- Dan Burton

On Wed, Jan 24, 2018 at 5:12 PM, Rick Owens wrote:

...
Dear Haskell Café,

I am a long-time Haskell developer with a proliferation of private projects. I typically make very heavy use of stack and LTS. Today, I tried to bootstrap my first project using LTS-10.* (with GHC-8.2.2) and I ran into an interesting problem (for me).

In the past, with lts-9.* and below, when I started cranking on some code and writing a bunch of imports:

...
import Control.Monad.Trans.Class (MonadTrans) import Data.Map (Map)

I would try to build first without updating the cabal file build-depends, and I would get something like the following error messages:

...
/path/to/Module.hs:48:1: error: Failed to load interface for ‘Data.Map’ It is a member of the hidden package ‘containers-0.5.7.1’. Perhaps you need to add ‘containers’ to the build-depends in your .cabal file. Use -v to see a list of the files searched for.

/path/to/Module.hs:21:1: error: Failed to load interface for ‘Control.Monad.Trans.Class’ It is a member of the hidden package ‘transformers-0.5.2.0’. Perhaps you need to add ‘transformers’ to the build-depends in your .cabal file. Use -v to see a list of the files searched for.

This was good because the error contained a suggested solution which contained the missing package, and I could sort of lazily add the build-depends I needed without having to memorize a (Module -> Package) mapping. I even had developer tooling to do it automatically.

With lts-10.*, however, the analogous error message looks like this:

...
/path/to/Module.hs:9:1: error: Could not find module ‘Data.DoubleWord’ Use -v to see a list of the files searched for. | 9 | import Data.DoubleWord (Word256(Word256), Word128(Word128)) | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

I am wondering, is there a way to bring back the solution suggestion? Not having access to it has made me realize how heavily I was using that feature. What do others think about this missing bit of supplemental error information?

Thanks,

-Rick Owens

_______________________________________________ Haskell-Cafe mailing list To (un)subscribe, modify options or view archives go to: http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe Only members subscribed via the mailman list are allowed to post.

_______________________________________________ Haskell-Cafe mailing list To (un)subscribe, modify options or view archives go to: http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe Only members subscribed via the mailman list are allowed to post.

Rick Owens

8:21 p.m.

FWIW, I discovered how to easily find the missing package using ghc-pkg: $ stack exec ghc-pkg -- find-module Data.DoubleWord /home/rowens/.stack/programs/x86_64-linux/ghc-8.2.2/lib/ghc-8.2.2/package.conf.d (no packages) /home/rowens/.stack/snapshots/x86_64-linux/lts-10.3/8.2.2/pkgdb data-dword-0.3.1.1 /home/rowens/projects/om-legion-objects/.stack-work/install/x86_64-linux/lts-10.3/8.2.2/pkgdb (no packages) Thanks to Dan for bringing up ghc-pkg, which I had not previously had occasion to learn much about. -Rick On Thu, Jan 25, 2018 at 11:32 AM, Rick Owens wrote:

...

Thanks for the help/info guys!

On Thu, Jan 25, 2018 at 3:51 AM, Michael Snoyman wrote:

...
Nice repro Dan! I hope you don't mind, I took your repro and opened a GHC Trac ticket about this:

https://ghc.haskell.org/trac/ghc/ticket/14717#ticket

On Thu, Jan 25, 2018 at 9:29 AM, Dan Burton wrote:

...
Hm, you're right. Seems like a GHC thing. I've tested a simple file with "import Data.Map" on both a stack project and a cabal project -- with containers installed in ghc's main package-db, as verified via stack/cabal exec ghc-pkg list containers -- and it doesn't give the hint in either case.

Taking it a step further and removing cabal/stack out of the equation...

$ cat Main.hs module Main where import Data.Map main = putStrLn "It compiles"

$ ghc-pkg list containers /usr/local/Cellar/ghc/8.2.2/lib/ghc-8.2.2/package.conf.d containers-0.5.10.2

$ ghc --make -hide-all-packages -package base Main.hs [1 of 1] Compiling Main ( Main.hs, Main.o )

Main.hs:2:1: error: Could not find module ‘Data.Map’ Use -v to see a list of the files searched for. | 2 | import Data.Map | ^^^^^^^^^^^^^^^

$ ghc --make -hide-all-packages -package base -package containers Main.hs [1 of 1] Compiling Main ( Main.hs, Main.o ) Linking Main ...

-- Dan Burton

On Wed, Jan 24, 2018 at 8:38 PM, Michael Snoyman wrote:

...
FWIW, I've also noticed that with LTS 10/GHC 8.2.2 I no longer get the package name suggestions, even when I know I have the package installed. I don't know if it's an issue with Stack or GHC, I haven't investigated. But I can't think of something on the Stack side which would make the behavior different between GHC 8.0.2 and GHC 8.2.2.

On Thu, Jan 25, 2018 at 4:02 AM, Dan Burton wrote:

...
I believe the particular feature you are talking about is a feature of GHC. Whether a suggestion is show or not merely depends on whether GHC sees the package in question in its package database(s).

If you are using stack, then you can look at one of your LTS 9 projects, and run

stack exec -- ghc-pkg list

In order to see the list of installed packages. (I think something like `cabal exec ghc-pkg list` should do the same for a cabal project.)

Identify the packages you tend to use, go into one of your LTS 10 projects, and `stack install pkg1 pkg2 ...`

Note that with stack, each minor version of LTS has its own package database, so packages locally installed into lts-10.1 will not necessarily be available in your local instance of lts-10.2. Repeat stack install to taste.

tl;dr the trick is to set up your package database so that GHC knows what to suggest for you

-- Dan Burton

On Wed, Jan 24, 2018 at 5:12 PM, Rick Owens wrote:

...
Dear Haskell Café,

I am a long-time Haskell developer with a proliferation of private projects. I typically make very heavy use of stack and LTS. Today, I tried to bootstrap my first project using LTS-10.* (with GHC-8.2.2) and I ran into an interesting problem (for me).

In the past, with lts-9.* and below, when I started cranking on some code and writing a bunch of imports:

> import Control.Monad.Trans.Class (MonadTrans) > import Data.Map (Map)

I would try to build first without updating the cabal file build-depends, and I would get something like the following error messages:

> /path/to/Module.hs:48:1: error: > Failed to load interface for ‘Data.Map’ > It is a member of the hidden package ‘containers-0.5.7.1’. > Perhaps you need to add ‘containers’ to the build-depends in your .cabal file. > Use -v to see a list of the files searched for. > > /path/to/Module.hs:21:1: error: > Failed to load interface for ‘Control.Monad.Trans.Class’ > It is a member of the hidden package ‘transformers-0.5.2.0’. > Perhaps you need to add ‘transformers’ to the build-depends in your .cabal file. > Use -v to see a list of the files searched for.

This was good because the error contained a suggested solution which contained the missing package, and I could sort of lazily add the build-depends I needed without having to memorize a (Module -> Package) mapping. I even had developer tooling to do it automatically.

With lts-10.*, however, the analogous error message looks like this:

> /path/to/Module.hs:9:1: error: > Could not find module ‘Data.DoubleWord’ > Use -v to see a list of the files searched for. > | > 9 | import Data.DoubleWord (Word256(Word256), Word128(Word128)) > | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

I am wondering, is there a way to bring back the solution suggestion? Not having access to it has made me realize how heavily I was using that feature. What do others think about this missing bit of supplemental error information?

Thanks,

-Rick Owens

_______________________________________________ Haskell-Cafe mailing list To (un)subscribe, modify options or view archives go to: http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe Only members subscribed via the mailman list are allowed to post.

_______________________________________________ Haskell-Cafe mailing list To (un)subscribe, modify options or view archives go to: http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe Only members subscribed via the mailman list are allowed to post.

2928

Age (days ago)

2928

Last active (days ago)

List overview

Download

6 comments

3 participants

participants (3)

Dan Burton
Michael Snoyman
Rick Owens