Opened 8 years ago

Closed 4 weeks ago

#4806 closed feature request (fixed)

Make error message more user friendly when module is not found because package is unusable

Reported by: mitar Owned by:
Priority: normal Milestone: 8.6.1
Component: Compiler Version: 7.0.1
Keywords: newcomer Cc: mmitar@…, Phyx-
Operating System: Unknown/Multiple Architecture: Unknown/Multiple
Type of failure: None/Unknown Test Case:
Blocked By: Blocking:
Related Tickets: Differential Rev(s): Phab:D4783
Wiki Page:

Description

Make error message more user friendly when module is not found because package is unusable. Currently it just reports that module is missing (the same as it even would not be installed) but then checking with ghc-pkg find-module shows package correctly. Chasing '-v' output around can then show you this but it would be easier that you would immediately get a helpful message.

Change History (37)

comment:1 Changed 8 years ago by igloo

Milestone: 7.2.1

Thanks for the report. It would be useful if you could paste the command you're running and the messages you're seeing, so we can be sure we're looking at the same thing.

comment:2 Changed 6 years ago by igloo

Milestone: 7.4.17.6.1
Priority: normallow

comment:3 Changed 6 years ago by igloo

Milestone: 7.6.17.6.2

comment:4 Changed 4 years ago by thoughtpolice

Milestone: 7.6.27.10.1

Moving to 7.10.1.

comment:5 Changed 4 years ago by thomie

difficulty: Unknown
Status: newinfoneeded

mitar: please add an example to show the problem. What do you mean with "package is unusable?". Thanks.

comment:6 Changed 4 years ago by mitar

See here an example of exactly what I am talking about here and how it confuses users. So user here has issues using Haskell program and module is said to not exist: `Could not find module 'Data.Vector'`.

But then you can see such error:

package vector-0.10.0.1-3450daae3d9f2092020075d05481123c is unusable due to missing or recursive dependencies:
  base-4.5.1.0-81d626fb996bc7e140a3fd4481b338cd primitive-0.5.0.1-15cdc8c11a54a78809b647af0c2975b3

So instead of saying that that module is not found which make one think you just have to install it, something else should be said.

comment:7 Changed 4 years ago by thoughtpolice

Milestone: 7.10.17.12.1

Moving to 7.12.1 milestone; if you feel this is an error and should be addressed sooner, please move it back to the 7.10.1 milestone.

comment:8 Changed 3 years ago by thomie

Keywords: newcomer added

comment:9 Changed 3 years ago by thomie

Priority: lownormal
Status: infoneedednew

comment:10 Changed 3 years ago by lstrano

Owner: set to lstrano

comment:11 Changed 3 years ago by thoughtpolice

Milestone: 7.12.18.0.1

Milestone renamed

comment:12 Changed 2 years ago by thomie

Milestone: 8.0.1

comment:13 Changed 2 years ago by mpickering

Owner: lstrano deleted

Please reassign if you still plan to work on this.

comment:14 Changed 23 months ago by Phyx-

Owner: set to bollu

comment:15 Changed 23 months ago by Phyx-

Cc: Phyx- added

comment:16 Changed 23 months ago by bollu

How do I reproduce this, exactly? If I'm fixing this, I'll need to know when the bug is fixed, so I was wondering what the correct way to reproduce this is. Do I damage my package database on purpose?

comment:17 Changed 23 months ago by Phyx-

@bollu, yeah, that seems like a reasonable thing to do, but I wouldn't go messing with your stage0 compiler (e.g. the one you use to compile the git source with the first time).

Just do a normal compile and corrpupt the stage2 compiler in the folder inplace that gets created.

comment:18 Changed 23 months ago by mpickering

You could also make a sandbox and damage the sandbox package database?

comment:19 Changed 23 months ago by Phyx-

Would the sandbox (I'm fuzzy on the details of it) also sandbox the actual package registration? e.g. does the sandbox copy the installed packages or just links to the ones already installed?

I must admit to not having used sandboxes before :)

comment:20 Changed 23 months ago by mpickering

They are installed in a completely separate database in ./.cabal-sandbox. So they or neither copied nor linked. I haven't understood this ticket but it's something that popped into my mind.

comment:21 Changed 23 months ago by Phyx-

Aha, no you're right, sandboxes would be ideal it sounds like.

comment:22 Changed 17 months ago by bollu

Owner: bollu deleted

comment:23 Changed 2 months ago by sgillespie

I can seem to reproduce the issue by running

cabal sandbox init
cabal install MonadRandom
cabal exec -- ghc-pkg unregister --force fail
cabal repl

Then import anything from the now-unusable package

Prelude> :m + Control.Monad.Random 
 
<no location info>: error:   
    Could not find module ‘Control.Monad.Random’
    Perhaps you meant
      Control.Monad.Reader (from mtl-2.2.2)
      Control.Monad.Cont (from mtl-2.2.2)
      Control.Monad.Error (from mtl-2.2.2)

comment:24 Changed 8 weeks ago by sgillespie

I think the strategy should be to modify mkModuleToPkgConfAll to include all UnusablePackages in PackageState.hs. We could then add another constructor to ModuleOrigin (say, BrokenPackage) so that we could report it on lookupModuleWithSuggestions.

Please correct me if this is not a reasonable approach.

comment:25 Changed 8 weeks ago by Phyx-

I haven't looked in great details but that seems like a reasonable approach to me. I'd say go ahead and give it a try!

comment:26 Changed 7 weeks ago by sgillespie

What specific message should we show? I was thinking:

Prelude> :m + Control.Monad.Random

<no location info>: error:
    Could not find module ‘Control.Monad.Random’
    It is a member of the package ‘MonadRandom-0.5.1-1421RgpXdhC8e8UI7D3emA’
    which is unusable due to missing dependencies:
      fail-4.9.0.0-BAHmj60kS5K7NVhhKpm9J5

comment:27 Changed 7 weeks ago by Phyx-

I would change the first part to be more precise

Could not find module ‘Control.Monad.Random’ into something like Could not load module ‘Control.Monad.Random’ since the message is a bit contradictory saying it couldn't find it yet it's part of a package it knows about.

comment:28 Changed 7 weeks ago by sgillespie

Agreed; however, GHC does display the same contradictory message with hidden packages:

Prelude> :m + Data.Map                                                                                                                                                                        
                                                                                                                                                                                              
<no location info>: error:                                                                                                                                                                    
    Could not find module ‘Data.Map’                                                                                                                                                          
    It is a member of the hidden package ‘containers-0.5.11.0’.                                                                                                                               
    You can run ‘:set -package containers’ to expose it.                                                                                                                                      
    (Note: this unloads all the modules in the current scope.)          

I think it would make sense to use the same language for both scenarios. I can either update both, or leave them both the same. What do you think?

In the meantime, I'm going to go ahead and submit a review so someone can start reviewing it

comment:29 Changed 7 weeks ago by sgillespie

Differential Rev(s): Phab:D4783

comment:30 Changed 7 weeks ago by sgillespie

I added my phabricator revision, but it doesn't appear to be building (we're on Step 1 for over 24 hours now): https://phabricator.haskell.org/harbormaster/build/47009/

comment:31 in reply to:  27 Changed 6 weeks ago by sgillespie

Replying to Phyx-:

I would change the first part to be more precise

Could not find module ‘Control.Monad.Random’ into something like Could not load module ‘Control.Monad.Random’ since the message is a bit contradictory saying it couldn't find it yet it's part of a package it knows about.

I toyed with this a bit, using "Could not load module" for hidden and unusable packages. It broke hundreds of tests, and I'm a bit uncomfortable with that. For that reason, I think it's best not to mess with that for now.

comment:32 Changed 6 weeks ago by Phyx-

It's quite common to have to update test outputs when you change user visible messages. I'd be more surprised if you didn't have to. In any case, will change it later.

comment:33 in reply to:  32 Changed 6 weeks ago by sgillespie

Replying to Phyx-:

It's quite common to have to update test outputs when you change user visible messages. I'd be more surprised if you didn't have to. In any case, will change it later.

After further review, it was only 2 tests. I updated them and added them to the phabricator revision.

comment:34 Changed 5 weeks ago by Phyx-

Thanks! The new error messages look good to me! I'll give dfeuer a few days to respond to your review.

comment:35 Changed 5 weeks ago by Ben Gamari <ben@…>

In df0f148f/ghc:

Improve error message when importing an unusable package

If a module cannot be found because it is ignored or from an unusable
package, report this to the user and the reason it is unusable.

Currently, GHC displays the standard "Cannot find module error". For
example:

```
<no location info>: error:
    Could not find module ‘Control.Monad.Random’
    Perhaps you meant
      Control.Monad.Reader (from mtl-2.2.2)
      Control.Monad.Cont (from mtl-2.2.2)
      Control.Monad.Error (from mtl-2.2.2)
```

GHC does, however, indicate unusable/ignored packages with the -v flag:

```
package MonadRandom-0.5.1-1421RgpXdhC8e8UI7D3emA is unusable due to
missing dependencies:
  fail-4.9.0.0-BAHmj60kS5K7NVhhKpm9J5
```

With this change, I took that message and added it to the output of the
"Cannot find module" message.

Reviewers: bgamari, dfeuer

Reviewed By: bgamari

Subscribers: Phyx, dfeuer, rwbarton, thomie, carter

GHC Trac Issues: #4806

Differential Revision: https://phabricator.haskell.org/D4783

comment:36 Changed 4 weeks ago by sgillespie

Status: newmerge

comment:37 Changed 4 weeks ago by bgamari

Milestone: 8.6.1
Resolution: fixed
Status: mergeclosed

This is already present in 8.6.

Note: See TracTickets for help on using tickets.