restrict `autoImports` to `base` or another list of libraries

[cxandru]

Is your feature request related to a problem? Please describe.
We teach a Haskell course and automatically grade student submissions. We do this using https://github.com/cxandru/haskell-submission-tester, where each exercise is tested by the test suite of a cabal project with specified dependencies. I assume that because of the way students' installation is set up they work in a global project with a bunch of packages available, so haskell.plugin.ghcide-completions.config.autoExtendOn imports things from all sorts of packages that aren't base, meaning we can't grade their submissions. Often nothing from the imported modules is even used. Imports include really strange things such as:

System.Directory.Internal
Unicode 
Network.TCP
import Control.Monad.Identity ( replicateM ) (instead of the sane import from Control.Monad)
import Distribution.Simple.Flag (BooleanFlag)
import Distribution.Simple.Hpc (guessWay)

all in exercises with business logic entirely unrelated to any of these packages. I can only imagine that the autocompletion runs wild completely.

Describe the solution you'd like

We would like to have students be able to still use autocompletion, but only for modules in base

Describe alternatives you've considered

Telling students to disable autocompletion entirely.
Supply students templates within a cabal project with restricted dependencies. I assume hls would then adjust what it suggests? The problem with this would be that it exposes additional complexity to students that might cause to more issues.

[fendor]

I am helping out in a functional programming course as well, and can only second this.
Since this semester, we had the most ludicrous import statements, something student would never come up by themselves and not used at all.
In my opinion, the unrestricted auto-import in combination with imperfect completion system yields bad results and causes bad experiences for students (and more maintenance for course administrators).

I assume hls would then adjust what it suggests?

We provide a template (containing only base and QuickCheck), but boot libraries are still suggested, e.g. from Cabal. As a work-around, we have resorted to accept any imports from GHC boot-libraries.

[pepeiborra]

Can I suggest that we focus on the issue before coming up with solutions?

Do you know what version of HLS your students are using? HLS 1.5 contains a good number of fixes to completions that will result in fewer strange imports.

If you provide your students with a Cabal descriptor that restricts the set of build-depends to base, as suggested by @fendor, the completions should no longer suggest imports from other packages.

@fendor can you report the issue with boot libraries in a separate ticket? I cannot seem to reproduce it for Cabal.

[fendor]

Do you know what version of HLS your students are using?

I suspect, most use either ghcup or vscode plugin, thus in the beginning of the semester, the version was 1.4.

fewer strange imports.

As long as the completion system is more of a heuristic, I still expect it to be wrong most of the time. But I will test it.

can you report the issue with boot libraries in a separate ticket?

I will test it to be sure, it is possible that students ignored the template and used HLS on a plain .hs file, which would result in this behaviour, since the default cradle probably includes boot libraries?

[jneira]

Well those kind of things always can be improved with some config option restricting which packages/modules could be take in account for suggestions
But setting and parsing that config option could bring other issues, like making suggestions empty due to some user error filling it.
🤔

[cxandru]

For anyone encountering this in the context of automated submission grading, we recently fixed this in our Python framework by parsing compile errors for import errors and removing the offending imports before trying again: cxandru/haskell-submission-tester@e51e133